Harness the power of scalability by separating build, release & run stages of your deployment pipeline for better reliability, faster rollback & independent scaling of processing and storage for a more cost-effective hosting solution.
This is the fifth video in our 12-factor Application Modernisation series. In this video, Marc Firth (Managing Director at Firney) explains software engineering best practices around separating Build, Release and Run stages of your deployment pipeline.
See our Application Modernisation with 12-Factor App series and the full App Modernisation playlist on YouTube.
A transcript of the video above is included below.
Immutable deployments
Marc: When it comes to the deployment of your Web service through your deployment pipeline, it’s really important that your Web service doesn’t change as it progresses through that pipeline. This is what’s known as immutability, and it helps in maintaining a stable release cycle as your web service progresses through that workflow. In this video, we’re going to go through why that’s the case and how to achieve it.
The “Build” stage
Marc: Hi everyone, so this is the sixth episode of our 12-Factor App series where we’re focusing on what it takes to build scalable, reliable and efficient applications that are easy to manage. Now, when you’re building your deployment pipeline, it’s important that you have a build stage at the beginning of your pipeline.
This build stage turns code at a particular commit into an executable by fetching dependencies and compiling binaries and assets.
Now, usually, when we do this, we’ll turn this into a docker image, and that makes sure that that image of our code is snapshotted and unchanging.
Create a “Release”
Marc: So the next stage in your deployment process is likely to be some form of release stage, such as to a staging or testing environment where we take that application’s executable and combine it with the correct config for the environment we want to run that executable on.
The “Run” stage
Now it’s likely you’ll have a few testing environments that you’ll be running various forms of tests on, but ultimately you’ll end up at a production environment.
When we get to this environment, it’s important that we’re using the same image that we’ve been using in our testing environments. But here we’ll be scaling up – likely to run on a Kubernetes infrastructure using much more scalable infrastructure, cloud infrastructure, for instance. So we want to make sure that we’re also testing in a similar environment to that, which we are going to be using in production. But, it’s very important that the image of our application doesn’t change as we progress through the stages of deployment.
Why make it immutable?
Marc: So why would we want to do that? Well, it makes sure that when we’re deploying, it’s repeatable. It also means we can take our build and create a release for any environment by combining it with a different config for that environment. Because we’re using the same builds in every environment, we can be sure that if we need to roll back to a previous build, it’s very easy to do so and we can be sure that it’s going to be the same because that image is immutable. It’s unchanging as it progresses through those environments.
Now, this immutability or standardisation and consistency in the way that we handle builds of our software means that we can then invest time in improving the build pipeline itself by adding additional testing stages to that pipeline and making it very reusable in the way that we work.
This will progressively enhance the stability and quality of our build. It means that we can spin up additional environments as necessary for additional testing before deploying into production.
The first five factors of our 12-factor app are making improvements
So with the first five of the 12 factors in place, we’re already seeing better immutability in the way that we run, design and build our software:
- There are less differences between those environments and it’s more consistent and repeatable in the way that we work.
- Our deployments and now more stable and we’re tracking everything in version control.
- We can take our immutable image between those environments and we can attach different backing services depending on the environment we’re running, such as using a managed cloud database in production.
So I hope that was useful to you. Don’t forget to like, subscribe and share. And I’ll see you in the next video.