Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

DevOps with Bamboo: connecting to Jira

Monday, March 26, 2018 Pablo Santos 0 Comments

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 and what I'm going to explain in detail in this post.

How pieces fit

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:

Filter branches with Jira status

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:

Reflect Bamboo status changes in Jira

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.

Note: Remember, the "Jira issue status" values must be valid values as defined in the Jira workflow. For this example, I customized my Jira workflow as follows:
Jira customized workflow

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:

Bamboo link to Jira

Also, in the Jira side, the task is annotated with build information, which is again quite useful:

Jira link to Bamboo

In the Jira dashboard, there will be information about builds:

Jira dashboard with Bamboo info

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 :-)

Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

0 comentarios: