How to migrate Atlassian’s Bamboo server’s CI/CD infrastructure to GitLab CI, part two
In part one of our series, I showed you how to migrate from Atlassian’s Bamboo Server to GitLab CI/CD. In this blog post we’re going to take a deep dive into how it works from a user’s perspective. Get started You’ve deployed the demo so it’s time to play with it to understand how it works. Let’s imagine that one of the members of our project is John Doe. He is a software engineer responsible for developing some components (app1, app2, and app3) of the entire product, and he and his team would like to test those components in several combinations in myriad preview environments. So, what does that look like? First of all, let’s make some commits to the app1, app2, and app3 source code and get successful builds upon those commits. After that, we should create releases for those apps to be able to deploy them (as the deployment part of the apps CI config only shows when being triggered by a Git tag, i.e., a GitLab release). A release can be created by launching the last step (manual-create-release) in a commit pipeline. That would give us a new release with the ugly name containing the date and commit SHA in the patch part (in accord to semver scheme): On the Tags tab for the same app you now can see a deployment part of the pipeline has been triggered by the just created GitLab release but no actual environments to deploy are displayed (the _ item in the Deploy-nonprod stage is not an env): Create an environment But before that we have to briefly switch to another team who is responsible for preparing infrastructure IaC templates. Navigate to the infra/environment-blueprints project and pretend you are a member of that team doing their job. Namely, imagine you have just created some initial set of IaC files (they are already kindly prepared by me and present in the repository). You’ve tested them and now you feel that they are ready to be used by the other members of the project. You indicate such a readiness of a particular version of the IaC files by giving it a GitTag. Let’s put a tag like v1.0.0 onto the HEAD version. You will see how the tags are going to be used immediately. But first let’s make some changes to the IaC files (e.g., add a new resource for some of the apps) and create a second Git tag, let’s say v1.1.0. So, at this moment we have two versions of IaC templates (or blueprints) for our infrastructure – v1.0.0 and v1.1.0. Deploy an app into the environment Now we can return back to John and his team. We assume John is somehow informed that the version of the IaC templates he should use is v1.0.0. He wants to create a new preview environment out of the IaC templates of that version and put app1 and app2 into that env. (Here starts a description of how a user interoperates with the infrastructure-set Git repo. Notice that though the eventual idea is that it should be a Merge Request workflow – where you first get a Terraform plan within a Merge Request and can apply such a plan by merging the MR – which is widely advocated by GitLab but for the sake […]
