The concepts of continuous integration, delivery and deployment arose from the shift to “small-chunk” software methodologies versus “large-chunk” processes. Waterfall development measures progress by weeks or months, whereas agile development gauges tasks in hours, days or a week at the most. Conceptually, both approaches employ a development pipeline of discrete steps from specification to coding to testing and deployment. However, the brisk, incremental pace of agile methodologies is what imparts that impression of seamless continuity.
Although the agile pipeline, observed from on high, seems to blur differences between continuous integration, delivery and deployment, they each have distinct roles. However, they share an underlying philosophy that favors incremental, stable momentum over big-bang, throw-it-over-the-wall practices. One of the fundamental characteristics of continuous software development is that task duration is short. One effect of that is a significant improvement in organizational responsiveness.
Developers tend to prefer working on code via a branch off version control’s mainline in order to reduce distractions caused by other developers’ contributions. Typically, this approach creates greater difficulty merging code back to the mainline than it saves. Continuous integration requires developers to work from a single shared code source without branching. Tasks must be well-scoped and completed in no more than a day. Integration efficiency increases, since it avoids combinatorial integration thrash due to multiple, broad changes with unforeseen side effects.
Continuous integration is greatly facilitated if an easy-to-use, automated unit test framework is included in the development environment. With such a framework, changes are thoroughly validated by the development team prior to builds and regression testing. Such a component usually resides on a dedicated server. If defects are found, they are more quickly remedied while the coding details are still fresh in the minds of developers.
After the build/integration process, but prior to customer deployment, lies the process of continuous delivery. It includes a staging environment that emulates the final production context as nearly as possible. Achieving production conditions requires such things as identical hardware, software configurations and production data to drive tests. Within this environment, business logic tests and user acceptance tests are performed.
In a typical waterfall process, a nearly complete version of the software under development would be delivered to the staging environment every month or so. In an agile methodology, however, incremental versions are constantly delivered via the development pipeline. As in continuous integration, the impetus behind this is enabling faster turnaround time on defects whether they appear in programming or business logic. Furthermore, it facilitates early customer feedback, which in turn reduces development efforts to accommodate customer requirement modifications.
It is improbable that your software’s customers require actual, live deployment of the software on a daily or even weekly basis. However, a fundamental principle of continuous deployment is that you could deliver software that frequently if the need arose. That characteristic is a natural disciplinary consequence of the continuous development and continuous delivery stages that precede it.
Continuous deployment lies on the same pipeline, works from the same shared code base and embodies precisely the same rapid, continuous change paradigm. It enables incremental feature introduction, measurement and early revenue generation without the burdensome overhead that would result from attempting integration, testing and releasing new features in a “whole-hog” fashion. New ideas enter the development pipeline and emerge into deployments in one or a few weeks instead of months later. Improvements can be added weekly based on real-world feedback.
The Role of Automation in Continuous Development
The success of agile methodology depends on instilling stability into the process from end to end at the start. If done correctly, the evidence is reduced development thrash, instant progress feedback and the ability to create a product that better meets customer requirements.
Automation is key to obtaining such stability, which in turn enhances the automation process itself. It is not unusual for early automation efforts to be fragmented over development, integration, delivery and deployment stages, but the ideal is a one-touch, end-to-end process that validates the stability of the project as a whole.
Overall, the operational goal of a “continuous” approach to software development is the reduction of overhead activities that slow down the implementation of new features and diminish the organization’s responsiveness to defects, changing functional requirements and market shifts. Metaphorically, it is akin to climbing a mountain slope step by step rather than spending months building a rocket-propelled sled to attain the summit in one go. At any point in a continuous process, you are able to measure your progress, adjust your route and keep both feet on the ground.