Don’t bother with Bitbucket Pipelines – yet

As a previously fairly (but not completely) satisfied user of Atlassian’s Bamboo Cloud product, I was upset (like manyothers) to find out that it was being sun-setted. But they’ve got a new product to replace it – BitBucket Pipelines, currently in beta. So I gave it a try.

For those who can’t be bothered to read below the fold: don’t bother checking it out.

Pipelines, as I’ll call it here, isn’t a Bamboo replacement. My understanding of this sort of thing is that it’s meant to be more streamlined than a standard build environment – it’s part of a “pipeline” into deployment. So I don’t expect it to be able to handle a complex build.

There are things I would like. I would like to get reports of failed tests without having to trawl through a Maven log. I would like to be able to have build artefacts that I can look at, and possibly reference from other builds. I would like to have an actual pipeline, where I could, say, build & validate, then deploy to a test environment, before promoting to production. But hey, maybe those are coming, or maybe they aren’t part of the newfangled continuous-delivery process Atlassian is pushing.

But… I can’t believe they don’t include notifications of failed builds. This is a bare minimum feature that they should never have entered Alpha, let alone Beta status, without. The very least a build system needs to do is let you know “Did it build okay?”. And they don’t have it.

Fancy notifications – Jabber/Twitter/HipChat/carrier pigeon – they don’t hurt to have (though the pigeons can make a bit of a mess), but they aren’t essential. But you can’t get away without offering email notifications of failed builds.

I personally doubt that this product will suit my needs when finished – I don’t think it’s intended to. But I can’t trust a product where the Goal Donors leave simple “failed build notifications” out of the system. Atlassian are obviously not dog-fooding this tool, which means it’s going to taste worse than dog-food.

Advertisements

Share this:

Like this:

LikeLoading...

Related

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 18 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for.
I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 16 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.
View all posts by Robert Watkins

8 thoughts on “Don’t bother with Bitbucket Pipelines – yet”

I’m the lead Product Manager on Bitbucket Pipelines and I used to work on Bamboo Cloud as well and I wanted to provide some context and feedback on Pipelines. I’d like first to thank you for your writing about your experience as it helps us to understand the gaps that we have in our services.

You’re right to say that Bitbucket Pipelines isn’t a Bamboo Cloud replacement. It is something new, something different that embraces a different philosophy about Continuous Delivery. Bamboo Cloud was built to be agnostic, highly configurable at a low level (pick your own agents hardware) and give a central place to control access to builds and deployments. This was helpful but we realised that for Cloud teams it was more important to have a solution that was fully integrated in their workflow, self service for teams and turn-key. Pipelines exists within your repository and the configuration is part of the code. You do not need to configure agents or queues and, thanks to Docker, teams can manage themselves their dependencies without having to ask a Build Engineering team to add or configure AMIs for them.

We’re still in early days of the beta and this is why we have some core features like tests parsing and notifications missing. We wanted to get some customers on board to get their feedback and build something better instead of replicating as is the existing features in Bamboo Cloud. This is important for us because we’re already seeing customers using Pipelines in a different way than what we used to see on Bamboo Cloud. We’re aware of the critical gaps we have to get the product to be ready for launch and we’re working hard on meeting these requirements.

Please know that there are many teams in Atlassian already using Pipelines every day, including the Bitbucket Pipelines team itself and we have a growing number of beta testers adopting it and giving us great feedback. Having a pull request based workflow helps a lot to bypass the need for notification but rest assured, notification is one of the top priorities for the team.

I look forward to seeing where Pipelines goes – but without notifications, I’m not going to try it myself beyond the quick experiments I’ve already done. I honestly don’t know how a team could be using it in anger (and without another build system as a backup) without being told if a build was a failure.

Yes I do agree that we do need notifications system else developer has to keep watch on maven progress every time, which is defeating the purpose of fully automated deployment. So waiting for notification system to be placed very soon.

Also, any idea how our bash script can understand whether build is successful or not and take action based on build results? We are writing our own bash script to deploy the build on our ec2 servers once it is packaged successfully.

I’m 99% certain that the pipeline build determines if it was successful or not based on the exit codes as well. If you mean how can an external tool look at the pipeline job and determine if it was successful or not – I suspect that would be part of a Pipeline REST API, which in turn is a feature not yet implemented.

Just as an update… Failed build notifications now exist. And then get delivered to you via email. With that said… It just says it’s failed, you’d still have to go through the build output log (which is has a great UI).