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; } } }

How to handle separate deployments/releases

Corky Mower_p9sszp

Hey all,

We've separated deployments and releases using feature toggles. So now we may deploy a feature but perhaps have it toggled off. So now the workflow isn't quite as linear and things are a bit more complicated in Jira. We can't neatly have one story go from left to right on a Kanban board.

Does anyone have any experience or recommendations for this kind of situation?

Cheers,

Corky

Comments

Judd Garratt - Path of Trees

Hi Corky,

We have a similar situation where we deploy some features before releasing them.

Our solution is to use the Jira 'releases' functionality for deployments (so we can still easily track what stories/bugfixes are in which deployment) and then we have a separate custom field for 'Release date' to track when a deployed story is toggled on.

For us, a story goes into a 'Deployed' status and then subsequently into a 'Released' status for easy filtering. We can then drill down into the 'Fix version' field for the deployment number or the 'Release date' custom field for the toggle-on date as needed.

It's not perfect, as I sometimes find myself bulk updating issues to add the 'Release date' (when multiple issues form the one feature), but it's low clutter, still lets us use the native 'releases' feature in Jira and is easy for us to grok.

Perhaps something similar might work for you too?

Happy to share more if you're interested

Yuri Lapin _Release Management_

Hi @Corky Mower

Trust you are well.

From our own experience and use cases of our clients we clearly see that there are to layers to it, in particular:

The layer of software components/artifacts that you deploy/release on a regular basis (e.g. ETLs, Backend, BFFS, Frontend, Widgets, etc.). This usually comes with toggle OFF.
The layer of business releases/features when you are turning ON, doing experiments, A/B testing and graceful rollout with fault back strategies

The two are interconnected as you need to understand that all required artifacts are deployed to specific environment and configured is a way that you can toggle ON.

This is the philosophy behind our Release Management App that has Kanban boards for each layers, ability to manage and track those dep[endecies and much more.

Try it out!

Cheers,

Yuri.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud