In the rapid evolving times of today, organizations face a big challenge to stay ahead of competition - not only in terms of offerings but also technology. The challenge is the ability to swiftly adapt to the changing market and business conditions - to keep up with the competition, rapidly evolving market and its potential, technological enhances, etc. This leads the organizations to the desperate need of a mechanism that enables them to not only release new features rapidly, but also gives them the ability to react to the changing business and market scenarios. The only thing that holds them back from achieving this is the ultimate requirement of stability of the existing systems in production. This ask by the organizations to increase throughput, innovation and stability at the same time, makes them aspire for Continuous Delivery (CD).
The first principle of the Agile Manifesto states: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
One of the Lean principles say, "Deliver as fast as possible."
If you combine both the above statements, it is what Martin Fowler says – "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time." In other words, Continuous Delivery is an advanced lean-agile practice.
The first step to achieve CD is to incorporate Continuous Integration, which means constantly integrating the code, building the executables, deploying them and verifying these by running automated tests. The second step is deploying the executables in an increasing production-like environments to ensure the software would work in production. The key is to enable the business to have the confidence to move to production at any desired time, even at a moments notice and without any anxiety attacks.
Continuous Delivery effectively implies:
- The software is always in ship-ready state.
- Keeping the software in ship-ready state is favored over adding new features.
- After every change, you can get instant automated feedback on the production-readiness of the system.
- Ability to deploy any version of software to any environment.
Continuous Delivery adds immensely to the prospects of improving quality and enhancing innovation. The immediate benefits of CD could be -
I. Reduced Risks - By favoring small and frequent releases, it is possible to detect the problems early, as well as easier and cheaper to fix them. Additionally, the real progress of the product becomes clear and tangible with each production deployment.
II. Increased Quality - By automating the entire process from checking-in the code to making a release, you can get over the manual process of verifying the product quality and production deployment, avoiding subtle errors and raising the quality benchmarks with each release.
III. Faster Reaction Times - By making early and frequent releases you get rapid user feedback on the value of the release to them. This cut in lead time makes even the team to respond swiftly to inline the product with the evolving demands.
Continuous Delivery is based on the following principles -
1. Create a repeatable and reliable way of releasing software - This is the most significant principle and all other principles derive from it.
2. Automate everything - Never do anything manually that can be automated. Every aspect of the process should be automated – building, deploying, testing and releasing, even the various environment setups should be automated.
3. Keep everything in version control - this includes source code, configuration files, automation scripts, database creation and change scripts, environment and infrastructure creation and configuration scripts.
4. If something is painful, do it more frequently - If something is tricky or painful, doing it more frequently will make you improve on it, then you can probably automate it and eventually it will become easier and painless.
5. Done means released - A feature is considered done when it is released to the user to gain value from it, and to provide feedback to improve it or build upon it.
6. Build quality in - Quality is extremely important, else you would inevitably create all sorts of waste further down the line. The teams can build quality by following XP practices like pair-programming, TDD, automation, CI, etc.
7. Everybody is responsible for the release process - It is everybody's responsibility to develop and deploy the software in production, and also make sure appropriate business value is derived out of it.
8. Continuous Improvement - No team can start delivering continuously in one go. It is a journey where you gradually tread changing few things at a time, inspecting and improvising further, improving with each step.
As a final word I would say, delivering continuously should not be considered only as a practice, but should be aspired to make it a practicing habit.