Who hasn’t experienced it? One of your software offers an update, you download the new version – and nothing works anymore. A call to support confirms it: An undetected software error has brought the new version to a standstill. The development team is already working at full speed to fix the bug.
This is an annoying and expensive matter, especially in automated production. Because by the time the software has been updated again, it is not uncommon for the corresponding plant to be at a complete standstill. It doesn’t help that all hell is breaking loose in the software company responsible to fix this critical error as quickly as possible. The frustration is high.
This would not have happened with Continuous Delivery!
More stable and faster development with Continuous Delivery
If providers develop their software using Continuous Delivery, users regularly receive reliably stable software versions. The concept originates from agile development and combines techniques, tools and automations to permanently improve software delivery (deployment). Used correctly, this process enables customers to operate smoothly – while at the same time reducing the development effort.
A central component of Continuous Delivery is, on the one hand, more frequent versioning with smaller development steps and, on the other hand, the continuous and automated testing of these developments. Both steps are closely linked, which is why Continuous Delivery is almost always used in DevOps teams.
If there are more updates with fewer innovations, the risk of incompatible changes decreases. At the same time, the automated tests help to check every tiny step for functionality – and to further minimise the risk. Customers thus receive software that is safe to use. They can update it at any time according to their own needs.
On the developer side, the team benefits above all from continuous versioning: Continuous Delivery reduces incompatibilities due to different software libraries, as it uses a central repository (often GitHub). All that is needed is an automation server such as Jenkins. It manages the automatic tests as well as the creation of new release versions and controls their automated deployment. Depending on the configuration, the Automation Server does this for all environments:
- Development,
- Testing,
- Integration,
- Customer application.
Once set up, the system tests changes in the application independently and also uploads them to the repository if they pass. If not, the tests provide hints and causes of any errors for faster bug fixing. Meanwhile, the actual development can continue – time-consuming development breaks for tests are thus obsolete.
A triad of continuous software development
Depending on the configuration of the Automation Server, different terms for Continuous Delivery are in use today:
- Continuous Integration, when the server-side automation only involves the merging of different application components. CI is particularly helpful when several (development) branches are developed at the same time.
- Continuous Delivery, when the automation extends to internal versioning. The operations team can then deploy it in a live production environment.
- Continuous Deployment, when the automation server can also take over the rollout at the customer. The customer then only has to start the checked update with a click.
It is not uncommon for these terms to be used synonymously – how much automation is in a corresponding development pipeline is therefore often a matter of definition.
No more defective software
Continuous Delivery makes a valuable contribution to the automation of software development. Used correctly, the concept relieves developers both in the unification of different branches and in testing and bug fixing. Software users, on the other hand, benefit from a faster and more reliable update policy. Total production downtimes due to software updates are now a thing of the past. Instead, you are in control of when you receive the latest – stable! – version of your software.
