Atlassian is ending support for all Server products in February 2024. Learn more about the benefits of migrating from Atlassian to GitLab here.
The clock is ticking towards the February 15, 2024, end-of-life date Atlassian has set for their Server products. Users whose workflows rely on on-premises deployments of Atlassian Server products are faced with the choice of upgrading to Atlassian’s Data Center or Cloud products or finding alternatives.
One of the Atlassian products that is impacted is Bamboo, a CI/CD solution. Whether you're simply looking for a new CI/CD tool or you're looking to consolidate your entire toolchain, the Atlassian Server end of life is a great opportunity to make the move to GitLab to take advantage of the automation, scalability, and security of an end-to-end DevSecOps platform.
In this blog post, we'll cover the steps you can take to migrate your Bamboo CI/CD setup to GitLab CI/CD.
How is GitLab CI/CD different from Bamboo?
Organization
Bamboo is structured around Projects and Plans. CI/CD jobs are grouped into stages, which are defined in a Bamboo plan along with other configurations that determine how jobs run. Bamboo projects are used to organize plans, which are classified into Build and Deployment plans.
As the name implies, Build plans can be configured to pull code from configured repositories and generate artifacts. These artifacts are picked by jobs defined in Deployment plans and are deployed to environments configured in Bamboo. Bamboo jobs are also composed of tasks, which can be a script, a task to pull code from a repository, or a task specific to a technology.
You also need to add code repositories to a Bamboo plan or a project, making it available to all plans under it, and set triggers for how Bamboo detects changes and runs builds.
GitLab is organized differently. Everything is in a single platform, with your CI/CD configuration provided as part of your code in a .gitlab-ci.yml file, from a group’s compliance pipeline configuration, or Auto DevOps when enabled and the .gitlab-ci.yml file is not found in a project.
Gitlab CI/CD configurations are composed of jobs, grouped into stages. How the jobs are triggered can be controlled by CI/CD rules and there is no separate configuration for deployments. Deployment jobs can be defined in the same CI/CD script in a deploy stage, with the deployment environment set.
Agents vs Runners
Bamboo uses Agents
to run builds and deployments. These can be local agents running on the Bamboo server or
remote agents running external to the server. GitLab uses a similar concept to agents,
called GitLab Runner, which uses executors
to run builds. Examples of executors include SSH, Docker, and Kubernetes. You can choose to
use GitLab SaaS runners or deploy your own self-managed runners.
Bamboo Specs vs .gitlab-ci.yml file
Bamboo is largely configured via the Bamboo UI but can also be configured as code using Bamboo Specs. Bamboo Specs can be defined using Java and other JVM languages or using YAML, with Java having more complete feature coverage than YAML. Bamboo Specs can be defined and stored in spec repositories, then linked to Bamboo projects.
The .gitlab-ci.yml file is central to the CI/CD workflow in GitLab. When included in a project, the defined configurations are executed against the project; otherwise, Auto DevOps automatically builds and deploys your application, when enabled. Templates and CI/CD components can also be added to .gitlab-ci.yml for complex use cases.
How GitLab steps up your workflow
In addition to building and deploying your application, GitLab provides a suite of features that allows for building secure applications fast and efficiently. These include:
- Application security: GitLab analyzes your application across the stages of the software development lifecycle with security scans such as Static Application Security Testing (SAST), Secret Detection, Infrastructure as Code (IaC) Scanning, Dependency Scanning, License Scanning, Coverage-guided Fuzz Testing, Container Scanning, API Security, Dynamic Application Security Testing (DAST), and Operational Security Scanning.
- Compliance and security policies: Understanding the results of security scans and putting policies in place is crucial to ensuring secure applications. You can set up Scan Execution or Result policies to ensure additional scans or approval requirements are added to comply with regulatory or self-imposed requirements.
- CI/CD catalog: Parts of CI/CD configurations that are used across multiple projects can be turned into components stored in component repositories that are discoverable in the CI/CD catalog.
- Packages and registries: Custom or local replicas of popular packages can be hosted with the GitLab Package Registry. You can also host container images with the GitLab Container Registry and Terraform modules with the GitLab Terraform Module Registry. If you frequently use public images or packages, you can use the Dependency Proxy to maintain a local cache.
Learn more about other ways to automate your entire workflow with GitLab CI/CD.
Convert Bamboo Specs to .gitlab-ci.yml script
For the purpose of this blog post, we will focus on Bamboo YAML Specs. You can export your Bamboo Plans as YAML Spec — learn more here. Now, lets walk through converting your Bamboo YAML Specs into GitLab CI/CD configuration.
Container image
First is defining the container image of the container your jobs will run in. By default, Bamboo uses Agents, which depend on how the host machines are configured. You can replicate the Agent’s environment into a container image hosted in the GitLab Container Registry.
If you already run Bamboo jobs in a container image, it will look like this in your spec:
