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?

Allan Flatoff Mar 12, 2019

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.

0 answers

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase

Friday Fun: What's your best vacation planning hack?

Let's face it, work can be challenging but fulfilling, especially when you enjoy the challenges thrown at you.  However for me, nothing compares to going on vacation (or holiday as some of you m...

536 views 26 4
Join discussion

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