Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Correlation of Jira Fix versions / Releases to code deployments or feature flags?

The terms "version" and "release" are a bit loaded in Software development.   They usually imply or infer a specific revision of a code base that is being introduced into production.   For online systems, such as web apps, a version usually represents a revision of code that is deployed to servers at any given time.   For packaged software, the terms release or version represent the state of code that gets bundled into an assembly and made available to users for download.

Documentation from Atlassian is a bit vague and usually notes that versions represent a "point in time for a project".   Sometimes a fix version is referred to as "the version where you plan on releasing a feature or bugfix to customers" . . . getting closer to the conventional usage of the terms.

How do you recommend using Fix Versions / Releases in Jira?   What types of issues do you associate with Fix Versions (e.g.  User stories that explain requirements?   Tasks that represent portions of work that go into satisfying a user story?)

For those of you who might be using feature flags, how do you deal with Fix Versions / Releases?   After all, with a feature flag, you can "deploy" new code, but you aren't necessarily "Releasing" it (from an end-user's perspective), until you enable the feature flag.   You can also partially release functionality with feature flagging, introducing functionality to a subset of users.

To me, the approach that makes the most sense is:

1) Associate issues representing deliverable functionality or changes (e.g. new features, bug fixes, maintenance) with a Jira fix version, and not other issues that might represent "busy work" (Elaboration tasks, design tasks, testing tasks, etc.).   

2) the scope of a fix version would include any deliverable issues that are code-complete and included in a release, regardless of whether the features are enabled with a feature flag.   From Jira's perspective, if you have included the complete code in a build and are moving it to production, you are "releasing" it.   

3) The status of the release itself would represent the status of the code deployment event.   All of the issues in the release are included in the build revision, and once that build is deployed to production, you mark the release as "released" in Jira.

One downside I see to managing releases as I've described here is that for teams practicing Continuous delivery, that they would be creating and managing a lot of Fix Versions.  Each little (complete) change they introduce to production would necessitate creation and management of a "Fix version".

What are your thoughts?  I would be especially interested in feedback from anyone practicing continuous delivery, Scaled Agile Framework or Continuous Delivery practices.

1 answer

@Allan Flatoff  I don't have an answer for you, but I can tell you we are trying to solve for this same issue:

"for teams practicing Continuous delivery, that they would be creating and managing a lot of Fix Versions."

We are also using Portfolio and Zephyr. Those, and Jira itself, seem to have a predisposition toward planned releases, where a team might releasing software every two weeks or so.  Per continuous delivery, we want to deliver software whenever it's ready for release, multiple times per sprint, with no fixed cadence. We also have multiple teams working in a single code base and want to avoid having to coordinate the build/release process across these teams. 

Right now, it's a _very_ tedious and manual process. I'm starting to think we are working very much against the grain with Jira, Portfolio and Zephyr and either they need to change, or we need to change the software we are using to manage our work.

I'm interested to know what you have learned over the past few months. Have you come up with any solutions you could share here?

Unfortunately I don't have a great solution yet.   

One approach that we are currently considering is to use Fix Versions in Jira for both deployments, and feature flag "releases".

For code deployments, one possibility we are considering is the ability to automatically determine what Jira issues are included in a code deployment.  This would be obtained via the Bitbucket API.  Our code deployment system has the Bitbucket commit ID associated with the build that is deploying.

I would be interested if anyone has any good solutions for tracking releases - both associated with code deployments, and "phased deployments" / feature-flag enabling.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Continuous Delivery

Our Atlassian Partners continue to support their customers during coronavirus pandemic

Across the world, governments and healthcare authorities are demonstrating the power of collaboration to find solutions to the COVID-19 pandemic, to protect our communities, and to get things back to...

1,520 views 0 11
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you