Traditionally, software developing organizations release new application features in cycles. Depending on the application and the organizational setup such release cycles take between 2 weeks and 6 months. Thus, new software is released between 2 and 26 times a year.
In theory, a typical software release cycle looks like this:
- Write code – a team of developers works on different application features. They add and change existing code.
- Integrate code – all the code changes are integrated into an existing code base.
- Stage code – a modified code base is manually deployed to some sort of staging environment (e.g. to a virtual machine over ssh).
- Test code – a quality assurance (QA) team tests the new release for errors and approves changes.
- Deploy code – after approval by QA, the code is handed over to an operations team and manually deployed to a production environment (e.g. to a virtual machine over ssh).
- Enjoy code – users can now use the new application features and everyone is happy!
So, what is the problem with this practice?
Expect the Unexpected - Errors Slow Down the Software Release Process
- The code change can be faulty without the developers noticing it.
- The integration of code changes breaks the existing code base without the developers/integrators being aware of this.
- The new code is not installed properly in the staging environment or does not work in the same way as on the developers machine, but the person setting up the staging environment does not notice.
- In general, manually setting up a production-like environment or deploying code to production is time consuming. Therefore, simplified environments and deployments are often used for development and staging. With this limitation, a complete quality assessment of the code changes under productive conditions is not feasible before before the release.
- The QA team finds the errors but with a considerable delay and without any idea of where to look for the root cause in the previous development steps of different developers. As a result, fixing the bugs requires endless back and forth between QA, operations and developers.
- Some of the errors slip into production or new errors are made while provisioning the production environment or installing the new code. This may cause production incidents and application downtime. Time-consuming, manual rollbacks ensue.
So, what looks straightforward in theory is a time-consuming, non-linear process in practice. Users have to wait a long time for new application features and can not enjoy the application without interruptions. The occurrence of human errors slows down the release process for software. Unfortunately, these human errors are inevitable. That is why developers and software engineers spend only between 25-35% of their time writing new code and about 50% of their time fixing bugs.
Fixing Bugs - An Activity That Consumes Resources But Produces no Value
According to the concepts of the Lean Management philosophy, fixing bugs (defects) is one of seven types of waste, i.e. Muda—the Japanese word for any human activity that consumes resources but produces no value. Spending 50% of the time for bug fixing basically means that 50% of the money you spend for your development resources ist wasted.
In Switzerland, a full time equivalent (FTE) of an experienced, highly skilled development resource costs your organization roughly CHF 240K a year—using a total cost of ownership calculation. Half of that—CHF 120K per developer working on your projects—is wasted money.
So, what can you do to stop wasting this money and make your software development become more efficient—especially, when human error is an integral part of development and therefore inevitable?
CI/CD Pipelines - Three Strategies for Wasting Less Development Resources
Three strategies help to avoid human errors and reduce the amount of time spent on fixing them.
- Automation – substitute repetitive manual tasks and integrate, deliver and deploy code changes continuously and automatically.
- Early error detection – detect errors and their root causes automatically and as early as possible in the development value chain.
- Easy recovery – enable a quick reset to a stable code version in case something breaks the productive application.
Automatic, continuous integration, continuous delivery and continuous deployment (CI/CD) pipelines allow you to put these three strategies into action. They help you develop robust and high quality software applications. You can save valuable time and money you would have spent for code integration, delivery and deployment or for bug fixing. You can deliver new application features fast and efficiently to your users. Thus, you can react quicker to changing user needs and reduce the time-to-market for your application. And in case something goes wrong, a rollback to a previous application version can be done with just a click.
A properly set up CI/CD pipeline reduces the Muda of software development. Ideally, your developers can free up 50% of their time and you can save up to CHF 120K per developer and year. A good CI/CD pipeline allows you to release robust software not in cycles, ranging from 2 weeks to 6 months, but multiple times a day.
If you want to learn more about CI/CD pipelines, feel free to talk to us. At EBMRIO.tech we support companies in setting up automated CI/CD pipelines for faster and better digital innovations. Benefit from our competencies in DevOps engineering. So your software tools and products can adapt quickly to changing market conditions and evolving user needs.