Bamboo vs GitLab

GitLab compared to other DevOps tools

On this page

Summary

Bamboo Server is a CI/CD solution which is part of the Atlassian suite of developer tools. It is available only in a self-managed configuration and is a closed source solution. Bamboo offers build, test, and deployment automation, and has tight integrations to Atlassian Bitbucket (for SCM) and Fisheye (for understanding how source code has changed), as well as integrations to over 150 other tools. In contrast, GitLab offers a git-based SCM, SCM integrations, and code change traceability out of the box in a single application.

Bamboo offers a GUI for defining build plans, but does not offer pipeline as code. Bamboo also offers deployment plans (which include the notion of environments and releases), pre-deployment visibility, and per-environment deployment permissions. GitLab also offers release tracking across environments and deep visibility into the changes in a deployment, but sets deployment permissions based on branch permissions.

Bamboo does not offer monitoring. GitLab includes monitoring as part of its single application.

Bamboo steps can be run in parallel across agents, and those agents can be auto-scaled based on need if Bamboo is configured for a feature called Elastic Bamboo. Elastic Bamboo requires the use of "remote agents", which you pay extra for (see pricing). Organizations who want auto-scaling are also locked in to using Amazon Elastic Compute Cloud (EC2) and paying Amazon separately for their usage. In contrast, GitLab does not charge per remote agent (runner) and scales with a variety of cloud and container solutions.

Weaknesses

Extending the native functionality of Bamboo is done through plugins. Plugins are expensive to maintain, secure, and upgrade. In contrast, GitLab is open core and anyone can contribute changes directly to the codebase, which once merged would be automatically tested and maintained with every change.

Issue: If I want to use git submodules then I shouldn't have to upload and configure SSH keys on each Bamboo Agent.

Key text: "Bamboo requires separate Git authentication for submodules. This involves either using HTTPS for submodules and providing the credentials through the job's environment variables, or configuring separate SSH keys on each build agent. Using HTTPS would render local builds unusable, requiring credentials every time. Adding SSH keys to every Bamboo agent is unmaintainable. . . . This reason, among others is a large part of why we have migrated away from Bamboo. We now use Gitlab and Gitlab CI for much better Docker and git support."

Comparison

FEATURES

Built-in CI/CD

GitLab has built-in Continuous Integration/Continuous Delivery, for free, no need to install it separately. Use it to build, test, and deploy your website (GitLab Pages) or webapp. The job results are displayed on merge requests for easy access.

Uses little memory, it runs fine with 512MB. Uses little CPU power since Go is a compiled language

Application performance monitoring

GitLab collects and displays performance metrics for deployed apps, leveraging Prometheus. Developers can determine the impact of a merge and keep an eye on their production systems, without leaving GitLab.

GitLab provides a dashboard that lets teams measure the time it takes to go from planning to monitoring. GitLab can provide this data because it has all the tools built-in: from the idea, to the CI, to code review, to deploy to production.

With GitLab CI/CD you can create a new environment for each one of your branches, speeding up your development process. Spin up dynamic environments for your merge requests with the ability to preview your branch in a live environment.

GitLab CI/CD cloud native architecture can easily scale horizontally by adding new nodes if the workload increases. GitLab Runners can automatically spin up and down new containers to ensure pipelines are processed immediately and minimize costs.

Easily debug your containers in any of your environments using the built-in GitLab Web Terminal. GitLab can open a terminal session directly from your environment if your application is deployed on Kubernetes. This is a very powerful feature where you can quickly debug issues without leaving the comfort of your web browser.

With multi-project pipeline graphs you can see how upstream and downstream pipelines are linked together for projects that are linked to others via triggers as part of a more complex design, as it is for micro-services architecture.

GitLab CI is capable of not only testing or building your projects, but also deploying them in your infrastructure, with the added benefit of giving you a way to track your deployments. Environments are like tags for your CI jobs, describing where code gets deployed.

Developers and QA can deploy to their own environments on demand while production stays locked down. Build engineers and ops teams spend less time servicing deploy requests, and can gate what goes into production.

Environments history allows you to see what is currently being deployed on your servers, and to access a detailed view for all the past deployments. From this list you can also re-deploy the current version, or even rollback an old stable one in case something went wrong.

With this feature you are able to use Docker containers on Windows directly, in much the same was as if they were on Linux hosts. This enables more advanced kinds of pipeline orchestration and management for users of Microsoft platforms.