In recent times, the technology has come a long way and it is advancing at a rate which is out of bounds for a single human to comprehend all at once. DevOps has played a huge role in gaining this momentum. Much have been discussed and said about DevOps all over the internet explaining it’s benefits to the organisations, the differences between DevOps and traditional process and most importantly the jargon “change in mindset” which has been quite successful in slowing down the organisations in this process of adoption, which is for their own good. It is indeed true, that it is not just about wiring a bunch of tools together and see if the lights are on on the other end. There is an entire team culture aspect associated with it which simply cannot be ignored. Adopting DevOps without the cultural transition is as good as buying a car without knowing how to drive it.
This post is NOT about explaining the benefits and differences of DevOps, a lot of content is available online for the same. Rather, it is about probable grass root level steps which an organisation may take to introduce DevOps with minimum disruptions based on my experience and discussions with fellows from the industry. Most of it focuses on the people aspect since the technical implementation of DevOps pipeline might differ per organisation. So, if you are new to DevOps, the written matter below would make more sense if you have already done initial basic investigation on the topic. If you are in search of “Where to start?”, then this post is for you and I hope you take away some value.
1. Embracing Agile
They say DevOps and Agile go hand in hand. This is true given their nature. Thus, as a first step you may want to check how well Agile methodology is being followed in your team. Make sure the Scrum Masters are in charge of making sure the team/organisation champions it.
2. DevOps Introduction
It is important to get everybody involved in delivery (Devs and Ops) on the same page. Initial grooming about DevOps methodology should be done for the team members. When the actual transition is about to trigger, regular sessions may be conducted to intimate them about their change of actions in the new mode of delivery. Making the team familiar at the beginning helps gaining the team’s momentum during adoption of the change. This activity also helps them getting the heads up of the activities they may have to do in the target state, perhaps, starting next sprint? Kidding. These things take time.
3. Source Code Management
Choose right tools for managing the source code. This is not new, but what is new is the way of using these tools in DevOps mode. Git is one of the famous SCM tool available today. Many organisations have successfully leveraged it by using Github as remote host or hosting it centrally on their premises. Your team does not need DevOps to use SCM so some of the Git basics are expected to be already in place. What would change is the way to manage branches. Multiple teams work on multiple features of the product. With the introduction of DevOps pipeline tools, pre defined rules would be set as part of protocol to promote code through environments. Create and publish the plan so that everyone in the team is on the same page about branching practices in the future. This is the link to A successful Git branching model for reference.
4. Test Management
Perhaps the most critical part of a successful DevOps model. Automation testing is inevitable. Do the readiness assessment of your development team in terms of the testing capabilities. The team needs to be able to perform any type of automated testing required by the project. If the team is not familiar in writing automation test cases, consider investing in upskilling the team. As part of Test Management, chalk out the plan for how unit, integration, end-to-end and may be even GUI test cases be automated. Starting thinking in terms of test execution infrastructure. Collaborate with the DevOps transition team to align and understand how to utilise shared resources (if any) to carry out satisfactory test execution in a continuous manner. Having a full proof test and QA plan in place ensures the quality of the end result.
5. Build Automation
Before beginning with this change, make sure the team is comfortable in future mode of operation with SCM and Test Management. Having reached a point where we have the confidence to take on the next change - it’s time to target build phase. Prepare a strategy which can answer the questions like - What should be the build target? Should we rebuild the code base at every stage or deploy the package built at first stage? Which stages should have stub support and to what extent? This is where the operations start to get involved. Make sure they move beyond runbooks and manuals. The questions listed here are just a conversation starters, in reality there are many aspects like build tool deployment, different tools for different environments, stub support etc.
6. Delivery/Deployment Automation
The difference between delivery and deployment automation is politeness. Well not really, but to put it simply - delivery only delivers the package and asks for manual permission before deployment can be done, deployment doesn’t. This is the operations part of the entire process. Since the time code has been committed by the development team, CI/CD pipeline has automated quite a lot of things while providing key information about the health, quality and robustness of the new release. Operation team also ensures the health of the environments as well as pipeline delivering new code through various stages. Thus, instead of running run books and using user manuals for post production support, their role changes to notifying the development team as soon as critical error occurs. The fix need not wait for any release schedule and the CI/CD pipeline takes care of it. This is where organisations achieve the DevOps delivery model.
Once the CI/CD pipeline has been stabilised, teams can start to think of introducing additional tools to smoothen the process even further. Not just addition, but planning should also be done for replacement of currently used tools. As the technology advances, there are newer more efficient tools which are being introduced in the market. Careful planning of similar transitions should be carried out, but only this time you don’t have to change the mindset. For example, there are tools to check the code quality, scan security vulnerabilities etc. which result as a great add ons to the existing CI/CD process.
These were some learning and observations addressing the challenges of DevOps adoption from people perspective. At the end, the end product which is delivered is the same, but the way to deliver it is radically different. DevOps embraces the idea of “failing early” so that the cost of failure at later stage can be avoided. Since it is a continuous process the package size being delivered is small as compared to bulk delivery in traditional approach. The amount of tests and quality gate it goes through is still the same, or may be even better since it avoids human error because of the automation tools in place.
Few years earlier, setting up the tool chain for DevOps used to be a huge task. In that, every tool which is part of the chain had it’s own set of worries and performance caps, which indirectly affected the end-to-end delivery. Health of the pipeline itself was a big headache for the organisations. Today, we have many platforms which provide automated solutions to provision and manage customised pipeline. I shall explore those tools in coming weeks.
DevOps is a huge topic and every step deserves a novel of it’s own. But I hope above write up has been of some help to you. Let me know what are your views and if you want me to explore anything specific.