Continuous delivery is the automation of the software build-test-deployment cycle. Builds can be done, automated...
tests run and the software deployed multiple times a day. Sometimes, features could be rolled out to production in as often as every ten minutes or so. A build master coordinates the automated testing and deployment of features to “production.”
Continuous delivery also provides for feature toggling, selective release of features to only certain users, and that can be chosen based on user characteristics. For example, the social media site Facebook uses continuous delivery to rollout certain features only to “female users between the ages of 18 and 34 in the US.” This enables rollout of new features only to selected users and could take the place of user acceptance testing even when they are fully deployed.
Continuous delivery considers software development a pipeline, with feature definition, design, development, build, automated testing and deployment all forming parts of the pipe. The idea here is that development is not managed with discrete milestones and releases, as in a traditional Waterfall methodology or a stories/sprints approach as in Agile development. Feature rollout is a continuous process.
Continuous delivery offers a number of opportunities and challenges for organizations.
Continuous delivery opportunities
- Strategic impact: Continuous delivery offers a way to roll out features faster than other methodologies. The end result is that little time is lost between conception of a feature and its availability in production. This offers a key strategic advantage for any company that uses this methodology, as opposed to competitors who may be using methodologies that require a longer delivery cycle.
- Lazy evaluation of features: Rather than do an elaborate requirements gathering, analysis and design of software features, continuous delivery enables features to be rolled out quickly with the evaluation of how useful they were or not, deferred past deployment. Feedback can be obtained after features are in production and they can be turned off, if they are negative.
- Feature toggling: Based on user characteristics, certain features are available to a user or turned off. Feature toggling offers a very rapid way of doing end user testing or even customizing the software for different kinds of users. It also provides a way of turning off or on a feature as needed at any time. This is a huge advantage for features that an organization is not sure of but wants to experiment with quickly.
- Value analysis possibilities: When gathering requirements, it is hard to predict the value of each software feature to users. Toggling enables continuous delivery environments to track actual usage by feature. This can enable the comparison of predicted usage vs. actual usage and by inference, predicted value vs. actual value of different features. Those that failed to be key features can be turned off.
- Better quality: When you do multiple build-test-deployment cycles a day, the test automation exercises the entire software many times a day, catching any software defect that slips through anytime, especially with unit tests are also rolled in. Better quality of software is ensured with continuous delivery.
- Reduction of software backlogs: Software backlogs have been an irritant for business within IT in many organizations. Continuous delivery has the potential of rapidly reducing software backlogs, simply by the fact that features could be deployed more rapidly than with other methodologies.
- Streamlining of processes: Continuous delivery requires a high degree of discipline at every stage of the build-test-deployment automation cycle. Implementation ensures streamlining of internal business processes for this to happen, ensuring efficiencies that may not have been there before.
Continuous delivery challenges
- High degree of development discipline: Smaller organizations with fewer decision makers may be more nimble than large ones. The high degree of discipline and close, quick coordination needed in a build-test-deployment cycle may not be possible in larger organizations.
- Granularity of features assumed: Large features may need to be broken down into smaller ones and accommodated in continuous delivery. Long running features may not be suitable for continuous delivery as this break down may not be easily possible.
- Methodology leapfrogging challenges: Many organizations are still in the process of evaluating and transitioning to Agile development methodologies with all the attendant difficulties in leapfrogging methodologies. Continuous delivery demands a higher level of process discipline than the other ones and as such may be difficult for such organizations to handle.
- Tool support on various platforms: Availability of automation tools for continuous delivery is best on Linux, and in other environments, somewhat spotty. This is especially true of organizations with legacy computing environments.
- Time to commit, validation challenges: Features may be deployed but still may need to be validated before being committed. Validation of feature usage and utility takes more time as compared to the earlier parts of the continuous delivery cycle. So even if a feature is developed, tested and deployed, it may take time for it to be committed. However, continuous delivery offers features like toggling to speed the data collection for validation.
The never-ending quest for software development methodologies that can produce better quality software, faster, has resulted in continuous delivery. It uses build-test-deployment automation to achieve its goals. It presents a number of benefits that the other methodologies do not, but only if organizations are able to overcome challenges in its adoption.
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.