nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Allan Flatoff

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.

Comments

Edmond McLaughlin

@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?

Allan Flatoff

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.

Thorbjørn Borup

I don´t have a tested answer but I have suggestions to how you can minimize the overhead.

I understand you challenges with using the release handling in Jira is that with continues delivery you will flood the Jira with many small improvements. Potentially you would release a new version per issue fixed or feature added for this service right?

Jira is not intended for this heavy use of the release version management. I have used the Fixed in method to collect a bunch of features for a release, enable us to warn users about major updates, and release a release note that enables users and developers ot identify what was changed since last major release.

In the end the main purpose of the release is to enable a communication with customers when to expect special features or bug fixes. Often this is related to big projects with many features and they are interested in when at least 60% of them are working before the MVP is met, so this would make sense to have a release at that point where we can track the progress.

With respect to keeping track of all the individual features and what version build they in or what container/microservice version this is added in, I would recommend using the Git history.

If you make sure to integrate Jira and git and apply a branching strategy where the naming of the branches are linked to the jira issue, you can easily get a list of Jira issues from you git branch history.

I gues that your deployment chain is somehow linked to you pull request review and thus a step in this deployment could be to extract the Git commits and store them in a release note , or post the information to a page. I bet there are many more ways to handle this in a overview inside Gitlab, or similar tools and thus avoid cluttering Jira with the many small releases.

I hope my insight help a bit, sorry I don´t have the full complete solution, but I hope you will give some feedback on what you are doing because to make us all wiser

ngonzalez

Hello, now there are new functionality that will help to separete the deployments and releases concepts in the feature: https://support.atlassian.com/jira-cloud-administration/docs/what-is-the-deployments-feature/

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

continuous-delivery