Deployment Pipeline is a concept of Continuous Delivery. In the simplest way possible explaining Deployment Pipeline I would say that it is an automated way of getting the software from version control into the hand of end user.
The process of getting the software from the version control such as Subversion or Git into the end user typically involves traveling through checkpoints. Those checkpoints (or steps) could be: Building the software -> Unit testing -> Automated acceptance testing -> Deployment into QA/UAT/Staging environment -> Manual QA -> Release into production.
Example process diagram for changes moving through the Deployment Pipeline.
For more detailed description of Deployment Pipeline I recommend this article http://www.informit.com/articles/article.aspx?p=1621865 from Continuous Delivery gurus (Jez Humble, David Farley).
No matter what is the process there is a need for tools to automate and support the Deployment Pipeline. This automation is typically handled by the Continuous Integration servers. Some of the CI server out there:
- GO from ThoguhtWorks
- Bamboo from Atlassian
- TeamCity from JetBrains
- Hundson and Jenkins from the OSS community
- Others, mentioned in here: http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software
I’m going to take a closer look on the way TeamCity supports modelling the Deployment Pipeline.
How to setup TeamCity
When designing the Deployment Pipeline it is very important to create number of steps reflecting delivery process that have dependency on a previous Steps (checkpoints) of the process. Among many features that TeamCity have, exists the one for adding Snapshot Dependency between different builds.
Picture below shows example of two TeamCity builds representing two steps in my project delivery.
Build called Acceptance tests on Staging has dependency on Deploy to Staging.
What this mean in practice is that TeamCity will execute the Acceptance Test on Staging build only if there is a successful Deployment to Staging environment.
Triggering subsequent builds
Subsequent build could be triggered automatically when previous build in the Deployment Pipeline was successful. For example, in out configuration Automated Acceptance tests on Staging environment are triggered automatically as soon as deployment finishes.
This is achieved by setting up TeamCity build to be triggered on Finished build, just like in the next screen cap example.
There are steps in the Deployment Pipeline that require and should be manually triggered. In our case the Deployment to Staging environment is manually triggered by user. This happens as we only want some versions and control when they are released into that environment. It is enough to remove any triggers from the Build Triggering configuration to make it manually triggered.
Viewing the build pipeline
Latest version of TeamCity (I’m using TC 7.1.3) has a nice feature in the project view called Build Chains. It’s nothing else but a unified single view of dependent builds (Deployment Pipeline).
Example pipeline from my project:
In our Deployment Pipeline, every commit of a code will trigger first build Clean and Compile the project. Pipeline stops at the deployment into smoke environment. Once confirmed the next station is a deployment into Staging. Final stop is the Release into production.
In our case the view of a build chain is the exact representation of our automated Deployment Pipeline.