It\u2019s about CALMS<\/strong>:<\/p>\n 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:<\/p>\n 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.<\/p>\n At this point, the Project Management Office\u00a0(PMO)<\/a> group within your company might suggest using a tool suite because \u201cthey use it today\u201d or \u201cwe got a sweet deal.\u201d This method isn\u2019t the best. Make your decision based on your goals and the features and options the tool provides to help you meet your objective.<\/p>\n Atlassian<\/a> provides two fantastic tools \u2013 JIRA<\/a> and Confluence<\/a> \u2013 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.<\/p>\n 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<\/a>, even they use Git internally.<\/p>\n 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 \u201cstory\u201d is \u201cinvestigate different tools\u201d or \u201cTECH SPIKE: Compare Git and TFS.\u201d Putting time on your sprint allows you to think through options and arrive at the best solution for your organization.<\/strong> You may have stories for saving build artifacts included here as well.<\/p>\n The \u201cBuild\u201d 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\u2019t use or even what you can or can\u2019t use. To work with agility, stay out of that trap.<\/p>\n 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.<\/strong> Put a tech spike in your product backlog to thoroughly investigate options before you make a choice.<\/p>\n You can also add stories in this spot for managing passwords (don\u2019t store plain text passwords in files!) during your build process, or you can even configuration management of properties and environment configuration values.<\/p>\n You know about the \u201cCI Engine,\u201d but did you notice I don\u2019t mention CI Engines in the diagram above? It\u2019s not because I don\u2019t 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, \u201cBuy our tool for $250K a year, and we\u2019ll support all of your needs for CI and CD.\u201d Don\u2019t fall for it!<\/p>\n Create a separate Epic for CI Engine and do your homework.<\/strong> From an open source perspective, one of the most popular CI Engines is Jenkins<\/a>.<\/p>\n\n
Getting Started<\/h2>\n
\n
![\"FullPic1\"](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2019\/07\/FullPic1.jpg\")
<\/a><\/p>\nRelease Planning<\/h2>\n
![\"FullPic2\"](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2019\/07\/FullPic2.jpg\")
<\/a><\/p>\nContinuous Integration<\/h2>\n
CI Engines<\/h2>\n