The eight practices for Containerized Delivery on the Microsoft stack – PRACTICE 8: Environment-as-code pipeline and individual pipeline

This post is originally published as article within SDN Magazine on October 13th, 2017.
During the past year I supported several clients in their journey toward Containerized Delivery on the Microsoft stack. In this blogseries I’d like to share eight practices I learned while practicing Containerized Delivery on the Microsoft stack using Docker, both in a Greenfield and in a Brownfield situation. In the last blogpost of this series I want to talk about Environment-as-code pipeline and individual pipelines.

PRACTICE 8: Environment-as-code pipeline and individual pipelines
Containerized Delivery means that you treat your application stack as cattle instead of pets. This means that you deal with the immutability and “stateless” characteristics of containers. The nice thing about those characteristics is that they make your containerized application stack reproducible and scalable. Instead of upgrading, you replace your application stack.
You can leverage from the above characteristics by extending your existing set of individual delivery pipelines with a combined pipeline that can deploy your entire application stack to production. You’ll still have a separate commit (build) stage for each individual application, but the other delivery pipeline stages (e.g. automated acceptance test and user acceptance test stages) are combined stages within this pipeline. At the end of the pipeline you deploy your entire application stack to production. As a result, you can choose whether you want to deploy your entire application stack at once, or whether you just want to deploy the newest version of an individual application.