So, what is Continuous Delivery? CD is about moving away from making software ready for release a separate activity, and instead developing software in a way so that it is always ready for release. This doesn’t necessarily mean the release process is quicker, but rather that there is a consistent flow between developing software, testing software and putting software into production. It’s about making the flow between development processes and operations processes seamless. Today, a lot of people have problems releasing their software into production because there is a real disconnect between development and operations. There is a tendency for these two organizations to operate as silos. Continuous Delivery, is about automating that flow from development, to testing, to operations, and making it as seamless as possible.
It’s important to highlight here that Continuous Integration is more development-centric. It’s about maintaining quality during the development phase; as changes are made, feedback is generated from these changes and this feedback is then used to constantly adjust. Continuous Delivery extends this concept of maintaining quality, maintaining readiness, and having a feedback loop throughout the entire process. CD touches all the participants in the software development life cycle, and ultimately within the application life cycle management process. So, traditionally, with Continuous Integration, we deal with: code, commit, integrate, and test. With CD we extend this concept to include activities all the way from planning, through release and maintenance.
There are various stages that flow together in a Continuous Delivery process, oftentimes referred to as the build pipeline. Essentially there are three stages to Continuous Delivery. The first stage is the “commit stage”, which is traditionally known as Continuous Integration. This includes all the development, source code management and testing. (which includes unit test frameworks, and code metrics on the low-level functionality of your code base). What you have at the end of the commit stage is a deployable binary that is now ready for functional testing.
Stage two, is “acceptance testing”. This is the functional testing stage, where the user stories that comprise the product are tested to make sure they behave correctly, so that they can receive the appropriate sign off. This is a very important piece of the pipeline as it connects the development and operations activities.
The third stage, involves putting the binary that passed the functional tests into various other testing environments such as a staging environments for exploratory testing and manual testing. After successfully passing these tests, it goes on to the implementation stage and then ultimately into production. As mentioned earlier, there’s a constant flow within these stages and the entire process needs to be automated as much as possible to be successful.
This is an excerpt from the webinar: Continuous Delivery: The Last Mile
What do you think? Leave a comment…