Photo by Max Duzij on Unsplash

For the last few years many of the projects I’ve worked on have utilized TeamCity for CI/CD, however, more recently I’ve made a point to build new CI/CD Pipelines using AWS Code Pipeline. As part of some other changes to one of the projects I’d been working on, I determined we should migrate that pipeline away from TeamCity to CodePipeline also.

TeamCity is a great tool, but there are a few reasons why I’ve been moving projects from TeamCity to CodePipeline:

We had to manage the underlying EC2 servers, keeping the dependencies up to date and common between servers started to become painful.

The TeamCity servers started to become bottlenecks in our deployment processes as the number of projects increased.

The templating system for TeamCity is lacking, making it difficult to repeatedly deploy pipelines between stages. The GUI required too much clicking around, which introduced the potential for human error.

The diagram below is a rough depiction of what the previous deployment flow looked like; it’s split into two main components — our serverless backend built on API Gateway and Lambda, and a frontend built with a combination .NET MVC and React, which runs on EC2. After TeamCity has compiled our code for the backend and frontend, CloudFormation handles the orchestration of the deployment of our APIs and Lambda functions backend, CodeDeploy handles the .NET frontend.

While CodePipeline takes over the orchestration of the overall process, CodeBuild is the primary service which has taken on the grunt of the work TeamCity was performing. One cool feature of CodePipeline’s stages is multiple actions per stage can run in parallel to help reduce the overall time your pipeline takes to complete.

After a bit of trial and error, our pipeline now looks something like below (we also snuck in a GitHub migration from an internal repo).

You may be thinking, where do Cross-Region actions come into it and why would anyone bother to use them? In the case of this project, the target customer base is Australian and so all resources are deployed in ap-southeast-2 — it makes sense to use CodePipeline in ap-southeast-2 also. Remember when I mentioned the frontend is a .NET MVC app? One little detail I left out is it’s built on the .NET Framework and not .NET Core. This means I needed to use a Windows Docker image on CodeBuild which isn’t available in ap-southeast-2 at the time of writing. To work around this problem, cross-region actions come to the rescue!

Cross-Region actions allow CodePipeline to perform actions in different regions to where your pipeline lives. If going through the wizard in the AWS Console, you’ll notice at both the Build and Deploy stages you have the option to choose not only the deploy provider but the region in which you want that action to take place. Useful for my case where I need to use a feature in CodeBuild which isn’t available in my region but can also be used to perform multi-region deployments in parallel.