In this post, I’ll show how to setup TeamCity so that your project’s build configurations are stored in your git repository. This allows you to change your build configuration in the same way you change your code, via a pull request. It allows to make changes to the pipeline without affecting other branches. And all that is supported in a way that you don’t have to give up the user friendly way of defining your build via the UI.

This is just a fun hacking post. I put together a script that is able to handle all versioning strategies that I mentioned about in the post about versioning.

I recently stumbled upon a tool called GitVersion which takes a different approach on versioning. I already mentioned some options regarding versioning, but all of them require you to actively specify the version somewhere. GitVersion instead is able to calculate it based on the state of your git repository.

According to Wiktionary, the word version means “a specific form of variation of something”. In computing, it’s “a particular revision of something” (e.g. software). The word has French and Latin roots. The Greek translation, έκδοση, can also be translated as publication.

In a previous post, we saw how to dockerize the build plan of an application. Typically, you’ll want the build to run tasks like linting and unit tests, and then publish the results of these operations as XML reports that the build server can consume and present in a human friendly way.

In the series so far, we have build a CI pipeline that produces a Docker image and a Helm chart. They are linked together with a unique version, allowing us to use Helm to deploy any feature branch we want. Now we’ll see how to implement a traditional DTAP and use Helm to deploy whatever, wherever.

In a previous post, we had taken a shortcut: we had TeamCity running inside Kubernetes, sharing its Docker daemon. That trick allowed Kubernetes to access the Docker images produced by our builds. In this post, we’ll setup our own Docker registry and publish Docker images there.

Before we continue with setting up the multiple environments that comprise our DTAP, I’d like to take a break and discuss a bit about networks. This way we can understand better what is going on inside and outside of Kubernetes.

In the previous post we created the Helm chart for our hello world blog-helm application. The Helm chart contains all the information we need to deploy our application to a Kubernetes cluster. But so far, we always deploy the latest version. In a CD setup, we’d like to be able to deploy any version, from any feature branch, at any given point in time, to any environment (DTAP). Let’s start by looking at versioning.

In the previous post we had a first look at Kubernetes and deployed our hello world app on a local cluster using the CLI. The simple commands we used are good enough for a first taste. However, the full power of Kubernetes comes with using configuration files. Helm builds on top of that, taking these configuration files to the next level.