Continuous Delivery - how to start?
In my previous article I discussed the benefits and drawbacks of Continuous Delivery (CD). Hopefully, I was able to convince you that CD is a must have if you’re striving to be a modern and innovative company. The next question on your lips, of course, will be: how do I start introducing CD into my organisation?
Continuous Delivery is more about cultural than technical change
Firstly, you need to change your entire team’s way of thinking. Usually there are developers, QAs, DevOps and managers in among the mix. They all have different responsibilities, but the whole team is responsible for successful deployment. And, when something goes wrong, it’s counterproductive for team members to start pointing the finger. Instead, teams need to learn to concentrate their efforts on getting delivery working again.
CD also ensures that QA and IT Operations staff are closely involved in working on the needs of the software. Discussing all the decisions, early on, with the entire team allows everyone to be on the same page in terms of architecture and risk. There’s nothing like preparation and CD allows infrastructure changes and code deployment to be tackled with relative ease when a firm plan is in place.
Due to the cultural changes and adjustments required to introduce Continuous Integration/Delivery processes, it’s crucial that your company has strong organisational basics in place to meet these needs.
How do I get started?
First of all, treat CD as a process that can be approached in small steps. Your next action should be to analyse your build process, write down all the steps and then focus on two things:
- Which steps take the most time?
- Which are the most error-prone and involve manual intervention most often?
These are the best candidates to automate first.
Once you have determined the steps to automate, you must build pipelines on your CD servers that will automate a trigger building process after each change to the master branch in your source code repository. In the beginning, make your pipeline as simple as possible. It is more important to have the whole process implemented and working so it can be improved and extended rather than focussing on each step independently and attempting to integrate it at the very end. This approach is favoured because you will face infrastructural issues during deployments or executing tests; it’s better to address the resultant issues right away, otherwise you will end up with an integration nightmare. Once your build process is automated and well-established, then it’s time to add tests to the pipeline. AtIn Solidstudio, we aim for over 90 percent coverage for unit tests, but it’s not a must in the beginning.
The next step is to add more and more tests to the build process. Starting with the unit, you should quickly introduce higher level tests, like api tests for REST services, end-to-end tests with various scenarios for web and mobile applications and a regression suite to ensure that nothing is broken. Finally, you may want to introduce performance tests for individual and crucial parts of the application.
With all the various tests in place, you may be confident that your application is working correctly and that your software is ready to be deployed at any time without major risks. Tests are a crucial part of CD, so it’s very important not to bypass writing proper tests during the development phase.
Of course, the whole process will be much easier if you are about to kick-off a new project instead of implementing it into an existing and complex application. However, even when starting afresh, it still requires a lot of discipline to introduce good practices to the project.
Continuous Delivery - next steps
CD is a process and, as you know, there’s always room to improve every process. In order to be able to improve anything, however, you need to know:
- What are the bottlenecks?
- What are execution times of each step?
- How much in terms of resource is consumed by the process?
In these cases, you need to monitor and analyse the data that comes from your CD servers. Once you identify any problems, work to address these issues. It will improve the whole process by reducing the time and costs of releases.
Despite some of the technical challenges and necessary tools, CD is more about the collaboration between individual people and teams. A team needs to feel like a team, there needs to be a shared concern about the quality of the project. With that in place you can be sure that team-spirit will increase and stress levels will drop among whole team. The final bonus is that your customer will love the shorter release cycle and constant evaluation of the product.