How to link Jira Versions to Stash (git) version tags

[Agustin Martin]

I'm trying to switch over from our current issues and change management system(*) to JIRA, STASH (and optionally BAMBOO). Currently we can tag our new versions/releases from our issues application when releasing a version. This kind of integration seems to be missing from Atlassian suite.

Trying also to use git-flow model for code development, does not make things easier with Stash. In my testing I have to do a lot of manual steps when releasing a version with Jira+Stash: Create a version in Jira, release it, follow git-flow model of release start ... release finish using the same version names (or doing it via Stash as an alternative). This feels cumbersome and error prone. Has someone found some best practises for easying this kind of integration?

 I wouldn't mind doing things from JIRA or Stash, but ideally I'd like to release a version from only one of them and have the release happen on both.

A possible solution would be from the JIRA release management page, find the most recent commit included in the JIRA version (let's call it X), and check that all other commits are ancestors of it (otherwise warn of possible problems when tagging in stash). Then automatically launch the tagging process in Stash: if X is in an open release branch, finish it, tagging the new version. If X is not in an open release branch, open one based on X, finish it, tag...

Going the other way around, another possibility would be starting from Stash, previous to git-flow release finish, do sanity checks against JIRA (the commits present in JIRA's version with the same name as the release branch are all ancestors of our current release branch). Then on release finish, make Stash also "release" the corresponding JIRA version.

Both options would requiere either much creative scripting or some additional support form Atlassian tools. (And still this is not ideal since we're not checking whether we are including extra code in our stash release that belongs to a different JIRA version)

Any thoughts?

Thanks!

(*) not relevant to the case but currently we use ClearQuest for issues and version planning, and ClearCase for VCS. Transitioning a "version" issue type in ClearQuest will tag a version in ClearCase code (taking into account that no extra activities not present in CQ version are included in the tagged version).

[Tim Black · Accepted solution]

Yes, it'd be nice if this feature was part of the Jira-Bitbucket integration "out-of-the-box", but I'm guessing Atlassian will never implement this since this functionality has no feature request and is entirely possible, and not very hard, to implement using these products' REST APIs. Releases are typically made only after a vetting process. These days it is standard protocol for this process to be implemented in a CI system which builds and tests your product on SCM events (pushing a commit or tag). 

So, I would propose the following solution (which is just one of many possible approaches) to your problem:

1. Configure your CI system to build tags, and to be cognizant of when the build was initiated by a release tag. (Should be able to set up a release tag convention and set up your CI system, e.g. Jenkins git plugin, to filter on specific tag regex.)

2. Modify your CI pipeline to inspect the build reason, and conditionally on successful build and test of release tagged builds, invoke the Jira rest API for creating and/or releasing a version (with same name as tag) in the corresponding Jira project.

After this work, your release process looks like this:

1. Create a release tag in Bitbucket repo

What if the build/test fails? The corresponding Jira version is not released, as you would want.

To handle this, I propose that you leave the pipeline logic alone (keeping it simple "is this a build of a release tagged commit?) and move the release tag to the next commit after you fix the thing that caused the release build to not pass.

[Agustin Martin]

Hey! Thanks for getting back on such an old thread!

Unfortunatelly we haven't seen any kind of official support for this feature (the only thing I miss from my old RUP-UCM times) in the past five years, so it's safe to assume it won't be in Atlassian's radar anytime soon.

I'll mark your proposal as the accepted solution since it's probably the most viable currently, even though we may miss extra features such as sanity checks on issues with modified code in the current branch but which are not part of the Jira "release". These could be further solved by complicating a bit the process via API calls I'm sure, but it would fall to us to implement them.

Thanks again for taking the time to make a possible proposal.

[Tim Black]

Re:

sanity checks on issues with modified code in the current branch but which are not part of the Jira "release

I would say that should be solved by creating policy and enforcement for commit messages always containing a valid ID for a jira issue. Then by including all the desired issues and a release you don't have that problem of dangling code changes not related to a jira issue.

There are a lot of ways to implement this, but ultimately it can't be a server side implementation only, which is why atlassian doesn't support this out of the box probably. You're developers need a system for sharing hooks in each of their git clients. Client side is where almost all commits actually happen.

[Agustin Martin]

Yeah, fortunately we have such a policy implemented with the YACC plugin for Bitbucket.

The problem arises sometimes when a specific feature with commited code is not ready to be shipped due to last minute issues, but there are ways for dealing with that also, from using feature flags, to reverting merge commits...

[Simon Fifield]

It's a shame you haven't had any responses to this query. We are trying to do something similar. I was googling how to do it and found this question.

[Agustin Martin]

I know. It's a pity, since this is one of the major hurdles preventing us from completely migrating to Atlassian. I find myself 8 months later with the same doubts I had then. But now its 2016, maybe we'll get lucky and Atlassian will include some functionality along these lines.