Often when I visit customers, I am asked “Where should we start?” The short answer is start with what hurts most. Some customers still ask again. They want a step-by-step list for implementing DevOps. The problem here is each customer is at a different stage of their DevOps transformation. So, where each customer starts will be different.
Nevertheless, if I had to imagine a customer in the worst possible situation, where would I begin with them?
First, I would make sure the team is using source control. I would not worry about centralized versus distributed. I would just need to make sure they have their code in a place a Continuous Integration (CI) system can retrieve the code to build. Source control also allows developers to easily recover changes they may have lost. I would employ the simplest branching strategy possible.
Next, I would make sure the team is firing on all cylinders as an Agile team. They need to be producing increments of shippable code, code we could deploy to an environment. I would make sure they are using some form of work item tracking for their Epics, Features, Product Backlog Items, Bugs, tasks and impediments. I would want to have a visible Product Backlog and/or Kanban board. This visibility will allow them to focus on a goal. This is also where I would focus on unit testing and make sure we are designing quality into the software. I would crystalize this in the Definition of Done for the team.
To verify that the code is good, I would make sure they have a CI system in place. Upon each check-in, I want the code downloaded, built, tested, and packaged on a separate build machine. I want consistent green builds, builds we have confidence in.
Then I would attempt to automate deployment into a single development environment (Dev). I would want to build confidence in the ability to deploy the code with no manual steps. Over time, others will see the ease in which you deploy to Dev and want to try it in other environments in your pipeline.
Once we can deploy into an environment, I would work on automating the testing of that code. In the CI build, we would run unit tests. But now that we have deployed the code, we can start to run integration and load tests. Automation is critical to increasing your velocity and reducing downtime due to human error. Just be careful and do not over-trust your automation. If your application has a user interface, chances are you would be remiss if you did not have a human at least verify the application before it is pushed into production. Automation is great, but it is not a silver bullet.
Once I can deploy the code into a static environment, I would introduce Infrastructure as Code and Configuration as Code to our pipeline. This will enable the teams to stand up new environments by simply changing some files in source control. There will be no need to visit portals or log on to servers to deploy your environment and your code. This will further reduce the chance for human error.
At this point, you should have a fully functional pipeline. The last piece I would introduce is monitoring. We must monitor our code as it is running in production to ensure we are delivering value to our end users.
Now take a look at your pipeline and find ways to further improve it. How can we speed up the areas that take the longest? How can we reduce our lead and cycle times? Keep in mind that implementing DevOps is not just about getting the right products in place to automate your pipeline. Sometimes it requires architectural changes to your application to enable it to be deployed in an automated way that does not impact your users.
Please use this post simply to give ideas as to where you can invest. The order will be dictated by where you happen to be on your DevOps journey.
Just because it is not broken does not mean you cannot improve it.