The path to continuous release In 5 steps to continuous deployment
Continuous deployment is the silver bullet of software release. But many view the process critically or have reservations. However, five steps lead to continuous release.
Companies on the topic
Continuous Deployment combines all process steps from continuous integration and continuous delivery and automates software deployment.
(© Cybrain – stock.adobe.com)
Agility requires being able to react quickly. After all, the development process of a product never goes straight – the market environment can change at any time, for example, or laws can create new framework conditions.
In order to be able to quickly meet changes in software development, it is recommended to set up so professionally that all capacity can concentrate on truly value-adding activities. Everything else should be completely automated.
Continuous deployment is critical to streamlining processes and keeping feedback cycles as short as possible. Because it is clear: If a newly developed function reaches the user as quickly as possible, you also get direct feedback – and the risk of developing a product past the user decreases.
Short definition
Continuous deployment is the tip of several successive continuous processes. The first of these is continuous Integration, the idea of regularly merging and compiling the code of several developers. This saves you the proverbial “merge-hell” later in the process, the great integration effort, if the code copies in the branches have moved too far away from each other.
The result is a main branch of the code base that is both compilable and includes all the latest developments. A dedicated machine such as Jenkins, Bamboo, TravisCI, or GitLab CI, which monitors code changes in the main branch and executes compilation and testing processes when changes are made, is recommended.
Continuous delivery goes one step further. The software is not only compiled, but brought directly into a deliverable state. After compilation and testing, a deployment pipeline takes over, which installs the software in a production-like environment. Nevertheless, a human is still necessary to trigger the deployment.
Continuous Deployment combines all process steps from continuous integration and continuous delivery and makes software directly available to the customer without the intervention of a person. In the end, there is a process that simplifies the work for developers and makes the rollout of new software just as pleasant for the users. Studies have shown that ideally the process is optimized so that all participants have more time for value-adding work.
Step 1 – automation of all processes
Automated deployments are safer and faster than manual operations. Therefore, the first step to continuous deployment is a good investment: The complete automation of all deployments. This is worthwhile even for anyone who does not yet dare to approach continuous deployment.
The aim is to develop a secure process so that a bug fix can still be made shortly before closing time without worrying about causing major damage. Of course, it is recommended not to blindly trust the continuous integration environment from the beginning. To be on the safe side, you can also deploy from a local machine at any time. Only it should really only be one ./ deploy command.
Step 2 – test and optimize
Do you trust your tests? In the meantime, you can assume that tests are available for almost every software project. The quality of the tests is only the crux: Is an error-free run of a test runner really so trustworthy that you can rely on the software to work?
True, the goal of achieving 100 percent test coverage is not dogmatic. However, more than one Happy Path should be checked, but also common scenarios that can cause errors. In addition, the test run time should not be a limiting factor for the frequency at which deployment can take place. If a test lasts three hours, then there is a great risk of ultimately skipping it. This only human risk should be avoided from the outset.
Step 3-Review Process
Fast feedback cycles are essential to detect early on whether a feature has been implemented correctly. Because the problem of an incorrectly created feature occurs much more often than that it does not work properly because of a bug. Personally, I advocate regularly looking at the working product together in a team with other developers. Alternatively, it is a good solution to publish each new Release, behind a Feature Toggle, if the appropriate infrastructure is in place.
Schitt 4-Observability
The core idea of observability is to know at all times whether the system is in order and to immediately sound the alarm in case of problems – and if so, also to have the tools at hand to be able to react. The background is that at a high speed of new releases, there must still be a control mechanism without having to check the system manually.
Usually, tools are used to check logs, metrics and traces. It is crucial that the resulting data also finds its way to the developer teams and is taken into account. Practical experience has shown that it is worthwhile to randomly select two people every day to check, based on a checklist, whether the program has done well in the last 24 hours, what it should.
Step 5-Improve Release Process
The focus of the continuous deployment strategy is of course the release process. With more than 20 deliveries a day, weaknesses in the process are hardly acceptable. There are some concepts that can help with this and together make the release process resilient enough:
Rolling Update: It is necessary to run the application in several instances at once. If this were not the case, every deploy would be accompanied by a short downtime, which could not be expected of any user. With a rolling update, the old instance can continue to run and respond to requests while the new version starts. After the successful start, the traffic is redirected. It should only be noted that both versions may access the same databases for a certain period of time. A database migration and a software change should therefore be split between two releases.
Rights-Based Releases / Feature Toggles: One tool to have two parallel code paths in the application is Feature Toggles. They allow switching back and forth between two paths via a” switch”. So releases from deployment can be done decoupled from the configuration interface and in case of an error, or if the change does not please, very easy to return to the previous version. In “Rights-Based Releases” this is used to unlock more and more user groups for a feature. It should only be taken to clean up the paths later.
Canary Deployments: Bugs can always arise – no matter how good the test procedures are. A Canary deployment serves to limit the effect of errors that can arise in production. For this purpose, a rolling update is used in several instances to monitor part of the traffic through an engine. If warnings such as HTTP 500 status codes occur in the new version, the deployment is aborted. The development team will be informed accordingly and can deal with the problem. The advantage: Everything that can go wrong initially only takes place in isolation.
Conclusion: An effort that pays off
Anyone who has dared to take the steps towards continuous deployment will not want to go back. Although the steps are associated with effort in all processes, but it ultimately results in a great deal of work facilitation for software development.
Those who have all the steps behind them and are still skeptical should take the time after the introduction to press the button every time to start all automated processes. So it gradually becomes normal and you can also take the last hurdle to continuous deployment and remove all manual intervention.
* Christian Uhl is Engineering Manager at Personio, previously he worked for several years as a Senior Software Consultant at codecentric AG and as Head of Engineering at Matmatch GmbH. Meanwhile, he has seen a huge variety of distributed systems and made a variety of mistakes that he can now share. He is particularly interested in distributed systems and microservices architectures and is always curious how all these parts fit together.
(ID:47371952)
