Introduction:

I have spilled a lot of virtual ink lately on Bamboo (Atlassian’s on-premise CI/CD solution), specifically regarding implementing “build as code.” To be sure it is a great feature that we here at Isos believe all Bamboo users should consider, both for existing and green-field installations. However the Bamboo product team at Atlassian has been very busy over the past two years implementing other functionality that deserves some attention. There are also a few other tips / hints our team of consultants have come across that many people might find interesting.

Tips:

With that in mind, here’s a quick random-ish list of three Bamboo topics we here at Isos feel might be important to you, the devoted Bamboo user:

#1 install a native git client

Bamboo comes with a Java implementation of git baked into the Bamboo binary bundle. With this fact in mind it should not be a surprise to anyone that a lot of Bamboo users are, as you read this, using that built in git client to do their daily builds. The problem with the built in client is that it doesn’t support features like (as stated in Bamboo’s online documentation):

  • symbolic links
  • submodules
  • automatic branch detection
  • automatic merging

Even if you are not planning to use any of the features above, you should still implement a native git client because there are actually more features that are not supported by the built in git client (like my favorite feature, build as code). What makes matters worse, Bamboo doesn’t give you descriptive error reporting when the internal git client doesn’t implement any of these features.

#2 use Docker for build isolation whenever possible

For years now, containers and Docker specifically have been the ‘hot’ technology for many organizations we here at Isos deal with. Well, to be specific, almost everyone wants to implement a Docker solution but questions about how to manage containers at scale in an enterprise still persist today.  Currently only a fraction of the Isos client base uses Docker for production deployments of the software they manage.

The hesitancy of using Docker (for good reason) causes many of our Bamboo users to overlook one of Docker’s most important features in the past two years: “Docker Runner.” This feature has the following features / advantages:

  • Isolation: It isolates the build process from the rest of the environment it runs in.
  • Security: Increased security of your environments by providing more strict control over resources the continuous integration (CI) process has access to.
  • Reliability: Reliability of your CI by making sure that environment it runs in can be reliably recreated each time you run your builds.
Currently, you need to make sure your build agents have ALL dependencies installed to any builds it might need to serve. This makes it so you need have more build agents and/or weirdly configured build agents. If you project can be built in a Linux environment,  you only need an agent with Docker capability.
Finally, any organization can use this feature without worrying about general enterprise management concerns in regards to Docker. Since Bamboo completely manages the Docker container’s life-cycle, container orchestration is not an issue.

#3 turn off the local build agent

If you can avoid it, do not use your Bamboo server as a build agent. We suggest this configuration for the following reasons:

  1. Security: Bamboo build processes can inspect anything the Bamboo main process has access to. Restricting builds to build agents insures developers can not access Bamboo configuration information (like database passwords).
  2. Environment reproducibility: Agents should only have the dependencies needed  to do a build, that’s it. The main Bamboo node will have more junk installed not needed for builds.
  3. Scaling: Moving builds to agents will allow your main Bamboo server to service concurrent builds / access.

Wrap up

Those are the three tips that we believe will make your Bamboo use go more smoothly.