DevOps with Bamboo: connecting to Jira
UPDATE 2018/04/04: We included a link to a webinar about DevOps with Atlassian Bamboo, Plastic SCM and Jira
To implement a full DevOps strategy, it is crucial to fully automate the testing and merging of each task branch. Automation is the way to achieve faster delivery of tasks required to fully implement DevOps.
I explained a recommended DevOps cycle and how to implement it with Atlassian Bamboo and Plastic in two previous blogposts.
Now, I'm going to cover how to fine tune the process by introducing Jira into the equation. What if Bamboo requires a given Jira task status to test and merge the associated task? What if the testing and merging process is reflected back onto the Jira task status? This is exactly what we released in 7.0.16.2063 and what I'm going to explain in detail in this post.
Recap: How Bamboo plan branches work
Bamboo plan branches monitor Plastic SCM looking for candidates to test and deploy.
What we improved in the Bamboo plugin was how filter the branches. By default, Bamboo simply gets all the available branches (which might be a consequence of a Git mindset; as soon as a branch shows up, Bamboo merges, builds and runs tests).
But, in Plastic, whether you work centralized or distributed, building every single visible branch wouldn't be feasible. If you are working by being connected to a central server, chances are that you checkin very often while the task is in progress. If you work centralized, you'd checkin to local, but frequently pushing to central for safety is not bad either. Trying to merge to main before the task is ready wouldn't be a good idea.
Hence, our first approach was to filter branches based on attributes. Only branches with a given attribute will be considered to create the plan and then be merged, tested and deployed. I covered that in the previous blogpost about Bamboo DevOps.
More powerful branch filters to create plan branches
Filtering branches based on attributes is good, but since we are describing branch per task, and every branch has an associated Jira issue, can we take advantage of it somehow?
I mean, you can go and update the branch attribute manually when you are done, but the most natural way of doing it would be to simply go to update the issue status in Jira.
So, we modified our Bamboo plugin to take that into account. So now, in addition to checking attributes (or alternatively, depending on your setup), it will also check the associated Jira issue status.
Under a plan branch configuration, you'll find something like this:
You must specify where your Jira host is, a user and password to let our plugin access, then the project, and how tasks are linked to branches. (Remember, we normally use the convention of a prefix + the issue number).
Finally, you set the status that your task needs so that Bamboo will consider the associated branch to merge and test.
Reflecting branch status in the Jira issue
Once the task branch is eligible for testing (and merging, etc), it is possible to reflect that change in the associated Jira issue. I mean, if the branch is under testing already, maybe it is interesting for you to set the Jira issue to testing. Or, once the branch passes tests and the merge is checked in, you might want the Jira to be in merged status.
To do that, there are a few more settings that you can tweak in the plan branch configuration:
As you can see in the image above, it is possible to make changes in the associated Jira task when the build starts, if the build or merge fails, when the build finishes correctly, and finally, if the merge can be completed automatically without issues.
A couple of tricks to achieve full integration
Did you realize that I defined the branch prefix as HDJ- and project key as HDJ? This is so that Bamboo and Jira recognize the "tasks" as a known element in both sides, and Jira automatically creates a link to the build and vice versa.
Here you can see how Bamboo detects that HDJ-3 is a valid Jira task, and provides a link to it, which is quite useful:
Also, in the Jira side, the task is annotated with build information, which is again quite useful:
In the Jira dashboard, there will be information about builds:
And just as a final note, remember that it is also possible to see Jira information inside Plastic, and create tasks after Jira issues directly, as described here.
Full merge automation in action
Bamboo will merge, build, test and then checkin branches that are marked with the right status, and also only if their corresponding Jira issue reached a given status value too.
The Bamboo + Plastic plugin acts as a merge bot, keeping the main branch pristine and helping you implement real trunk based development + devops on top of your task branches.
Watch the following webinar to see how to implement a full DevOps cycle with Atlassian Bamboo, Plastic SCM and Jira:
Looking beyond the Atlassian toolset
We are improving the integrations of Plastic SCM with different CI systems to allow our users to implement DevOps best practices out of the box. We described how we work a few months ago and we realized that it wasn't that easy to implement it out of the box without certain customizations here and there.
We strongly believe the branch-per-task workflow we always recommend is essential for DevOps, but we discovered it was hard to implement for some teams. While many went through the process of customizing their build system to monitor branches and trigger builds, we understand we must take responsibility of the entire cycle to help Plastic users succeed.
At the time of writing, we have already deployed many improvements to implement DevOps automation with Bamboo and Jira, but we are already working on moving up the integrations with TeamCity and Jenkins to the same level.
There's much more to come on this subject over the next weeks, so stay tuned :-)
0 comentarios: