We will finish a sprint with stories tested and "Done" and thereby closed in Jira. They often sit in a branch somewhere until someone remembers we have code waiting to be pushed live. Or worse, we go to push something live and someone will pipe up with "oh that also includes xyz change...", or even worse we push one change not realising it includes another one. Usually, it works, because it's tested, but kinda scary we don't often know exactly what going live without doing a thorough code review of all merge requests and diffs across multiple services/components.

Often we can't push things live immediately as there are dependencies, related work in progress, marketing or any number of other reasons. I know feature flags are a good solution but we're not currently planning to implement.

How do you track issues and related code that is Done, but not yet released in a methodical manner so you can see the code changes involved and the issues involved across any environment at any time?


Jira has release management capabilities built in.

If your business processes are such that you don't know up-front when a release will be made and what its contents will be, you can use those release-management capabilities like this:

  • when the code for a ticket gets merged into the master branch (or whatever branch the next release will be created from), fill in Jira the "fix version" field with the value for the next release.
  • Jira has a "Releases" view that can show you all the tickets that have a particular release in their "fix version" field. This can be used to know what changes you are getting in your next release.
| improve this answer | |
  • The problem I've had with fix versions is management overhead. The order of stories being released changes, or there are many releases across multiple services/applications on the same Jira project, or tracking multiple changes across different Jira projects, manage all this by tracking fix versions becomes a problem in itself. – DLT May 19 at 2:34

In addition to Bart van Ingen Schenau's answer regarding the use of Jira's release management functionality, you can also use workflow statuses. You can have post-development workflow statuses in Jira. Items in these statuses don't need to appear on the boards used by development teams, but you can then use boards and filters based on the Fix Version to identify the state of this work. This can be useful if you have a staged rollout to different environments or several versions beyond development-done at a particular point in time, but it does add additional workflow complexity.

The core solution, however, would be to use the Fix Version field to allocate a version to every issue and then release those versions appropriately. Other solutions can sit on top of this to add additional information that may help track where the work is.

| improve this answer | |
  • Thanks, I'm looking for a solution that's closer to the code rather than the project. I think a combination of "post-development workflow statuses in Jira" and using triggers to update status on code merges may be the solution I'm looking for. This way you can tell what hasn't been merged to master (not released) but also if it is merged the status is automatically updated. – DLT May 19 at 2:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.