Configuration as code allows the entire configuration of Bamboo plans to be stored as source code. It moves the managing of plans from the Bamboo UI to the developer's integrated development environment (IDE). This approach brings a lot of benefits.

In a world of UI-driven configuration

Prior to Bamboo 6.0, the only way to manage projects and builds plans was via the web UI, and few REST endpoints with limited functionality. It required the user to manually create plans and add stages, jobs, and tasks to them. The user had to define source code repositories, triggers, credentials, artifacts, and much more. Although Bamboo provided shortcuts for some actions, such as cloning an existing job or plan, sharing repositories or plan branches feature, it still required a lot of effort from the Bamboo administrator to manage it.

Advantages of configuration as code

Automation and standardisation

As configuration is written as source code, you can use all best development practices to optimise it, such as: creating reusable definitions of plans, parameterisation, using loops to create lots of different entities like plans, jobs, or repositories.

It is especially crucial for large Bamboo instances with hundreds of plans. Also, in the micro-services world, it's quite common to have similar build plans.

Versioning of changes

You can store configuration code in a version control system, such as Git, to see who changed what and when in your Bamboo environment. You can use tags to mark versions that have been published to Bamboo. You can use branches to isolate changes under construction and to work in parallel streams without affecting your production Bamboo instance.

Traceability of changes

If source code is versioned and properly managed (e.g. tagged), you can track which changes have been applied to your Bamboo server. Analysing code differences (e.g. via git diff) is quite often more convenient and efficient that reading audit logs in Bamboo.

Smooth promotion of changes from test to production

In case you use two Bamboo servers - a production and test instance - it's a lot easier to promote changes using configuration as code. In the "UI world", you had to click through many UI pages, test that everything works and next tediously repeat the same steps on the production instance. With configuration as code you can simply deploy plans to a test instance, verify changes and then deploy to the production instance just by changing the target URL.

Keeping build environment in sync with a product

It's quite common to keep a build configuration in the same source code repository as the product being built. As your product evolves, so does the environment needed to build it. Thanks to this synchronisation, you can always set up a proper environment, no matter whether you want to build the latest commit from the master branch or a bug fix branch created a few years ago.

Coding assistance and validation

Editing build plans in an IDE (such as Eclipse or IntelliJ IDEA) allows to you use IDE features such as: code autocompletion, parameter tool tips, pop-ups with JavaDoc, code refactoring, searching for usages of a given method/object and many more. You can also quickly perform offline validation by compiling and running the code.