Working with Git workflow in Bamboo and BitBucket
In a recent project, we had to work with BitBucket and Bamboo. Normally we develop using GitHub and Travis, which can be overwhelming the first time you use it. We quickly got used to all the features Travis offers and it was in this recent project that we found out they were features we really liked and even depended on. Most notably the building of pull requests and the display of the build status in the corresponding pull request.
In our project, Bamboo would only build the develop branch. We, as good developers following the Gitflow workflow, set up a testing server where the develop branch would be deployed to. But since Bamboo only built the develop branch, we would never reliably know if a pull request would pass our extensive testing suite until it was too late. The develop branch would get messed up and one Monday morning, when the branch broke for the oh-so-many-time, we decided this madness should stop. I started investigating the wondrous world of Bamboo + BitBucket (BBB from now on) and hoped I could find a way to stop this workflow heresy.
Into the fray
As I was clicking through Google, one thing became more and more apparent: building pull requests in Bamboo is not officially supported. The official Atlassian JIRA contains multiple tickets (some even as old as two years) requesting this feature, but none of them are in development. Quite a setback, but I remembered you could set up webhooks in GitHub. Surely, BitBucket has those too and I started crawling through the Atlassian API.
As it turns out BBB actually can build pull requests, but you have to write your own webhooks and triggers for it. For us, that wasn’t an easy thing to do. We had little experience with BBB and above all, we didn’t really have time to do it. I found some plugins on the Atlassian Marketplace, however most of them are either for Stash (now BitBucker Server) or haven’t been updated for years. Again no luck.
By now my research had taken a few hours and I was getting desperate. Did we really have to use a CI tool that didn’t really do CI? Then I stumbled upon a tutorial – from Atlassian themselves – showing how you can “configure” a gitflow workflow in Bamboo. Maybe that could be of help? After all, we used that workflow!
Quickly I opened Bamboo, made a build plan, configured it per the tutorial’s steps, created a repository on BitBucket, created a new feature branch, made some edits and opened a pull request. I switched back to Bamboo and I couldn’t believe my eyes: sure enough that new feature branch was building! When the build was done, I switched back to BitBucket and a nice green check mark in my pull request assured me everything was alright and merging the request wouldn’t break anything.
As you might have already asked yourself while reading this post and the tutorial, I wasn’t building pull requests. In fact, I was building a branch I wanted Bamboo to build since that branch name started with feature/. I gathered my team and explained what I found out. We decided that building feature and hotfix branches throughout their lifespan was actually desirable. That way, we would always know that a change we pushed would break the build. Now we would be able to fix errors as soon as they popped up, which fits the SCRUM mindset of delivering only working features.
My search for a way to build pull requests in BBB eventually led me to a CI configuration that fits perfectly into the gitflow workflow. Though I prefer GitHub + Travis over BBB, I no longer see BBB as an impediment but as a valuable asset to our workflow. The team always knows what pull requests are safe to merge and the constant feedback whether a branch fails to build or not is a good incentive for the team to code as best as we can. I hope this post can be of help to people who are looking to integrate BBB into their workflow or just want to build pull requests without lots of configuration. Because changing two config fields is literally all you have to do.