Continuous Delivery - Foundation, Configuration Management, Continuous Integration, Implementing a test strategy, build and deployment scripting, the commit stage
The content here is under the Attribution 4.0 International (CC BY 4.0) license
As we know software nowadays exists to support the business rules and I believe that it is a huge problem to programmers as well as everyone involved with software development. As the business grows, the software might change as well but change isn’t the problem, the frequency might be.
How can we deal with requirements today that change tomorrow? How can we guarantee our software quality? And most important how can we deliver value as we lear on the go? Value is something that the business has after the software has been deployed in production, not before. Before production, is an inversion. Often release to production is something to worry about, hundreads of memes and rules are out there “don’t deploy on Fridays”, “A simple change that took down production”.
Software delivers no revenue until it is in the hands of its users. As strong as it sounds, most organizations transform the release of software into production in a manually intensive, error-prone, and risky process (Humble & Farley, 2010) - p. xxxiv. The question that follows is: how can we deliver software to production in a safe and continuous fashion?
Foundations
Continuous Delivery is more than a tool, it is a practice, a process it might even change how you think about software. You can’t just say, today I’m going to start to use Continuous Delivery. It takes time and a lot of work to get there. Continuous delivery is the ability to continuously integrate with production code, which means you must deploy often. Continuous Delivery is about having a releasable version in any version.
Software development is about change
Authors like Kent Beck, Martin Fowler have said for years that the dynamics of change is the real deal in software development.
Thinking about change, it requires developers to shift the understanding of it to a different one: every change is, in effect, a release candidate. Every time a change is committed to version control, the expectation is that it will pass all of its tests, produce working code, and be released into production [1, p. 24].
A note from the practice of Continuous Delivery (CD)
If you think about that, it hurts other philosophies of software development. Let’s take into account GitFlow for example, it is a branching model that helps you to manage your code, but it is not the only one. GitFlow is a good example of how to keep making changes and avoid releasing the software. It is a good example of counter point for continuous delivery. It is posible to apply the same strict rule of every change is released into production with GitFlow, however, it will require many repeating stps in the process. The idea that every change is a release candidate, as proposed by Continuous Delivery, clashes with the branching model of GitFlow. In CD, each commit is treated as a potential release, requiring thorough testing, validation, and deployment into production. This philosophy assumes that any change has value and should be made available to users quickly - Dave Farley explores both approaches in a youtube video.
However, this approach can lead to a different set of challenges when applied to GitFlow’s feature-based development. With CD, every single change becomes a candidate for release, regardless of its significance or relevance to the larger project goals. In contrast, GitFlow encourages teams to focus on specific features and releases, prioritizing those that bring the most value to users.
Configuration Management
The start point is Configuration Management. It will enable us to manage all configurations needed for an application. Nowadays is common to have version control in projects, but I’m sure that a team somewhere is not using it. To use Continuous Delivery is mandatory to have a version control such as git or svn.
Every single artifact related to the creation of your software should be under version control (Humble & Farley, 2010) - p. 33. It is about managing dependencies, it is almost impossible to write software without dependencies. Usually, we do use dependencies when we are developing something that is not the core business of the application, take as an example Maven, NPM, Composer, Bundler, etc. Those tools are used to manage dependencies.
To display a PDF, to connect to the bank, to log in with the user’s social media account and so on. Configuration is the key for any software, usually when developing, programmers use their environment, QA people use others even in the production environment could be different, it means we must have good management in the configuration because sooner or later problems will show in configurations and Continuous Delivery gives to exactly proceed.
Continuous Integration
Continuous integration is an interesting topic because often people confuse Continuous Integration with Continuous Delivery (Martin Fowler, 2012). It is true that to do Continuous Delivery we have to have to use continuous integration. To create a simple continuous integration flow there are a few steps to do. The first step is to check regularly your version control, test suite, and keep fast the feedback from CI (Continuous Integration) server, Jenkins (Jenkins User Documentation, 2020), Travis CI (Travis CI User Documentation, 2020), GitLab CI, GitHub Actions for example.
To implement continuous integration is to create a paradigm shift in your team. Without CI, your application is broken until you prove otherwise. With CI, the default state of your application is working, albeit with a level of confidence that depends upon the extent of your automated test coverage. CI creates a tight feedback loop that allows you to find problems as soon as they are introduced when they are cheap to fix (Humble & Farley, 2010) - p. 82.
Implementing a test strategy
One of the very first steps of Continuous Delivery is testing. To have a good suite test which you can easily trust to run and believe that if a green bar shows up everything is fine, is essential.
Testing is a cross-functional activity that involves the whole team and should be done continuously from the beginning of the project (Humble & Farley, 2010) - p. 84. We can have different types of tests and different purposes the figure below shows us how to understand them what are each type of test and when we apply them.
The testing quadrants are a good way to understand the different types of tests and how they relate to each other. In this blog I explored the different types and shapes of tests, and how they can be used to improve the quality of your software.
The deployment pipeline
If you aren’t familiar with CI you don’t know what a deployment pipeline is, we use a deployment pipeline to build a flow where we can deploy the source code into production, the pipeline has steps where each one has a simple purpose, for example, unit test, also the steps used in the pipeline usually were made manually in the past.
At an abstract level, a deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users. Every change to your software goes through a complex process on its way to being released (Humble & Farley, 2010) - p. 107.
To build a pipeline depends on which project you’re working on. The best pipeline for your project could be worse than mine. This brings us to a unique way to develop pipelines, but of course, following some rules and best practices.
Build and Deployment Scripting
So far we realized we need to create a new culture, test things and also automate our deployment flow, and to achieve that we need to use a build tool. As soon as the project extends beyond a single person, spans more than a few days, or produces more than a single executable file as its output, it demands more control if it is not to become complex and unwieldy (Humble & Farley, 2010) - p. 143.
In Java world we have Ant and in PHP we have Phing, both are build tools and have a lot of features. Those build tools help us when or application gets too complicated to deploy or is taking several steps, as a consequence we reduce errors and increase our productivity. However, those are not the only way to build and deploy, it is based on the programming language ecosystem, each one will have a different approach. In fronted for example, typescript is used to build the application and output the javascript code.
The key point for having a script is the automaton part, reproducibility and versioning is the key to have the confidence to deploy as much as needed.
The commit stage
Welcome to the one of most important stages in your new pipeline, the commit stage. The commit stage represents, in more ways than one, the entrance into the deployment pipeline. Not only is it the point at which a new release candidate is created; but it is also where many teams start when they begin to implement a deployment pipeline (Humble & Farley, 2010) - p. 169.
If you’re going to implement CI the commit stage is the most important step. Usually, developers send to the repository incomplete features and some bugs as well, which makes this stage a dangerous stage. When deploying with continuous integration we must keep in mind that each commit can be delivered to the production.
Resources
References
- Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley.
- Martin Fowler. (2012). Continuous Integration. http://www.martinfowler.com/articles/continuousIntegration.html
- Jenkins user documentation. (2020). https://jenkins.io/doc
- Travis CI user documentation. (2020). https://docs.travis-ci.com
Changelog
- May 19, 2025 - Updated content with practical examples and references