Core capabilities for running a successful DevOps implementation include Release Planning and Continuous Integration allow you the ability of continuous development of software.
Setting the Stage
You attended the latest webinar or conference where the talk was all about DevOps. “Just use DevOps” or “DevOps it, man” were common phrases tossed around. You already use Agile in your organization, so you are familiar with terms like product backlog, sprint backlog, stories, and enablers.
You understand Capabilities, Epics, Features, and Stories. You think to yourself, “Hmm, maybe I’ll get this DevOps thing to work in my organization.”
You certainly can. However, before you do that, let me clarify something first. “DevOps” is not a thing or title. You can’t go to the supermarket and buy two pounds of DevOps. Nor can you employ a DevOps Engineer and expect him to implement DevOps in your organization in a matter of months. DevOps is a mindset that takes time.
It’s about CALMS:
- Changing how you develop custom software
- Automating processes
- Adopting a Lean mindset
- Measuring your progress and Sharing your findings
Getting Started
So, where do you start? DevOps is a critical component of your value stream and has five key capabilities on which we want to focus:
- Release Planning (RP)
- Continuous Integration (CI)
- Continuous Testing (CT)
- Continuous Delivery (CD)
- Continuous Monitoring and Observability (CM)
Now, the first thing an engineer does when given these capabilities is putting tools next to each of the capabilities. Avoid doing that! Think about how you want to break down those capabilities. Those breakdowns are your Epics.
Release Planning
At this point, the Project Management Office (PMO) group within your company might suggest using a tool suite because “they use it today” or “we got a sweet deal.” This method isn’t the best. Make your decision based on your goals and the features and options the tool provides to help you meet your objective.
Atlassian provides two fantastic tools – JIRA and Confluence – that cater to agile development quite nicely. Not only should you include stories about tool setup, but you need to add stories around your process as well. This step allows your stories to flow from sprint to sprint, and you can handle your respective backlogs (product and sprint) appropriately.
Continuous Integration
Starting with CI centers around where your code resides. You want to version your code in a manner that allows for easy access for developers, restricted access for others, and an easy reviewing process. Git is a top-rated tool with these abilities. Since Microsoft acquired GitHub, even they use Git internally.
However, the tool is not the point here. Having an Epic allows you to think about what you want to do in this space. Your “story” is “investigate different tools” or “TECH SPIKE: Compare Git and TFS.” Putting time on your sprint allows you to think through options and arrive at the best solution for your organization. You may have stories for saving build artifacts included here as well.
The “Build” Epic provides you the story-telling ability to complete the build portion of your pipeline. For Java applications, there are a couple of options such as Gradle or Maven to build your code. A word of caution: some of the folks in your internal organization might dictate what you should or shouldn’t use or even what you can or can’t use. To work with agility, stay out of that trap.
The tools you choose affect the ease of use for your team, the ability to implement quickly, and the flexibility of that tool to meet your short- and long-term needs. Put a tech spike in your product backlog to thoroughly investigate options before you make a choice.
You can also add stories in this spot for managing passwords (don’t store plain text passwords in files!) during your build process, or you can even configuration management of properties and environment configuration values.
CI Engines
You know about the “CI Engine,” but did you notice I don’t mention CI Engines in the diagram above? It’s not because I don’t find CI Engines valuable. This area is now the most confusing part about DevOps. Tool vendors start having a field day with CIOs and IT Managers, saying, “Buy our tool for $250K a year, and we’ll support all of your needs for CI and CD.” Don’t fall for it!
Create a separate Epic for CI Engine and do your homework. From an open source perspective, one of the most popular CI Engines is Jenkins.
I spoke to Kohsuke Kawaguchi at a conference last year. Kohsuke wrote Hudson, which is now Jenkins. He is the CTO of CloudBees and focuses on Jenkins Product Development. Even he agrees there is no such thing as a “one size fits all” CI Engine. Do the work and find a CI Engine that fits your needs. I have used Jenkins for years, and, in my experience, it fits most organizations’ needs.
Defining Stories
Define similar stories for “how you want to address unit testing,” “how can I analyze my code for issues,” or “are there any security concerns with my code.” The last one is critical if you develop an API or website people use regularly. You don’t want customers exposed to security concerns through your website. Not a good look.
Once you execute on all those stories, checking the code into Git triggers an automation to build your code. If the build completes successfully, it triggers unit tests. If the unit tests all pass, Git analyzes the code base for code quality and security issues. Again, if you trust the automation to do its job, this process is hands-off. Remember, test data must be in place in the test or staging environment for a successful run.
Finally
We began part one of this series looking at Release Planning and Continuous Integration. These capabilities now allow you the ability of continuous development of software.
Next time, we’ll talk about Continuous Delivery and Continuous Testing.
