CI/CD ?
In the old way of delivering software (Waterfall), most of the time is spent on development. The application can goes without being run for months. You only build and deploy the application and submit it for a test phase in the end, getting bug reports in large volumes late in the project. On the other hand, In continuous delivery, you have an application that on every code commit is automatically built, tested, and deployed to a production-like environment. Unit tests and automated acceptance tests are run, and the code either passes or fails these tests within minutes. Which ensures that the code is always in a working state.
- Continuous integration is a practice where code changes are automatically built and tested as soon as they are committed to the version control system.
- Continuous delivery assures that code is always in a deployable state, with every change passing through automated tests and quality checks before being ready for deployment. In other words it’s the additional layer of deploying every change to a production like environment, and performing automated integration and acceptance testing.
- Continuous deployment extends this to another level where every change goes through full enough automated testing that it's deployed automatically to users without manual intervention.
The 2024 state of DevOps report found that high-performing IT organizations could deploy on demand, far surpassing their peers in deployment frequency and efficiency. Always put in mind that top IT organizations are able to quickly move from concept to cache, allowing for rapid experimentation and market validation of ideas. These organizations deploy code 30 times more frequently, with multiple deployments occurring daily rather than weekly or monthly. You might think with rapid cycles and high frequency of change, you’d see a decrease in quality. But in fact, the reverse is true. This agility results in not only faster deployments but also fewer failures and quicker recovery times when issues do arise. This increase in quality happens because instead of doing inspection at the end of the development life cycle, we’re integrating testing earlier in the delivery pipeline, and instead of 1 huge go live consisting of 100 of changes, we evaluate and deploy changes 1 by 1, testing every commit and making sure the software is in a running state.
“It’s not how much you can deliver, but how little”
- Best practice: The 2024 State of DevOps report also highlights the importance of having branches or forks with very short lifetimes, ideally less than a day before merging back into the main trunk. This practice is crucial for achieving continuous delivery and high performance. Organizations that maintain branches for shorter durations and limit the number of active branches can integrate changes more frequently, reducing the complexity and risk associated with long-lived branches.
