How to migrate Atlassian Bamboo Server’s CI/CD infrastructure to GitLab CI, part one
When I faced a task of migrating from Atlassian Bamboo Server to GitLab CI/CD, I was not able to find any comprehensive information regarding something similar. So I designed a process on my own. This demo shows how to migrate a CI/CD structure for an existing multi-component application from a discontinued Atlassian Bamboo Server to GitLab CI/CD (Community Edition). The accompanying repository is https://gitlab.com/iLychevAD/ci-cd-for-a-multi-component-app. In this first part of a two-part series, you will find a description of the current state of affairs – i.e., how the CI/CD has been organized within Bamboo Server, how the Bamboo Build and Deploy plans are designed for bootstrapping infrastructure and deploying the components of the application, and the architecture of the application itself. And in part two, we’ll take a deeper look at the virtues of GitLab CI/CD. Initial state (Note: This is not a description of some particular project but more a kind of compilation of several projects I worked on.) The application solution allows the client to fulfill a particular business purpose (the nature of which is not relevant here and thus not specified) and consists of more than 50 discrete components (further referred to as applications or just apps or components). I refrain from calling them microservices as each of them looks more like a full-fledged application communicating with other siblings using REST API and messages in Kafka topics. Some of them expose a web UI to external or internal users and some are just utility parts serving the needs of other components or performing internal operations, etc. Code for each app is stored in its own Git repository (further just repo). So, a multi-repo approach is used for them. Each app may be written in different languages and packaged as one or several OCI-images for deployment. Each app repo looks like: 📦 ┣ 📂src
