How we fell in love with Bamboo YAML Specs

[#1]

What’s all the hype about?

Back in version 6.0 of Bamboo, Atlassian released Bamboo Specs (Configuration as Code).  From the beginning I was completely sold on the feature.  Being a solo Build Master, this would give me the power to write Java-based code and keep it in source control to manage the configuration of all our build plans.  My colleagues on the other hand were not so impressed.  Being a Microsoft shop the idea of writing code in Java was equivalent to wearing a Star Trek uniform to a Star Wars convention.

Even though I wasn't making the popular choice I decided to prove Bamboo Java specs could be useful for us. We have a few build plans for our internal NuGet packages which all follow a standard convention for being built so this seemed like a good place to start.  Our Development Managers saw the benefits, as creating new plans went for taking about an hour for me to complete to taking minutes to create.  Still, I was the only one making any use of this awesome feature.

Are we ready to jump in?

I've been keeping my eye on the growth and maturity of Bamboo specs as a feature, and the introduction of YAML specs looked as though it would gain much more traction at our company.  As of the launch of version 2.0 of YAML specs it supports creating build plans, deployment projects/environments and permissions for plans and projects.  This is a large enough feature set to make the case to start using it.  It has been two years since I first tried things out with Java specs, so I decided to pitch the concept of using YAML based repository specs to several our senior developers, and they were excited about the idea and wanted to learn more.

I created a small proof of concept in one of our independent repositories to show how this would function and to provide a template for others to follow.  Now, several of our developers have started writing their own specs files. We generally only use script tasks since the majority of what we use to build and deploy our applications are powered by PowerShell scripts.  This means that the learning curve is smaller and it lowers the bar of entry to get other developers in our company to adopt this as a standard of practice.

Why is this so great for us? 

Being the sole administrator responsible for the operation of our Bamboo server, as well as having other job duties, this reduces the bottleneck of requiring me to update all our build plans, while still keeping a comfortable level of managed control over the changes that are being made via the source controlled specs files.

This also gives us an audit of who changed what, and when they changed it, with an easy method to revert changes that have unintended results.  This is something that isn’t as easy when using the GUI editor today.

Lastly, our developers are familiar enough with the YAML syntax from other projects we already have and are willing to work within that syntax.  This allows us to setup Bamboo specs in any repository, and the developers feel empowered to be able to make the changes as they alter the way the application builds without having to wait for me to get around to it with my busy schedule.

Final Thoughts

In conclusion, it has taken us much longer to start using Bamboo Specs than it should have, but we are excited about how much potential this will unlock for us, and I would highly recommend that others check it out if you haven't already!

[Alexey Chystoprudov]

Thank you for your story!