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 do you manage releases when code moves to production and fails?

Shalane Sheppard

Hi there, if you assign tickets to a planned release and then once they migrate to production, some of the issues fail. Do you assign them to a patch release; therefore mapping the ticket to more than one release? 7.8, 7.8.1 and wait until it passes before closing the prior release?

I am interested to hear about your processes. We do frequent releases of code. High priority tickets migrate regularly.

Accepted answers

Martin Bayer _MoroSystems_ s_r_o__

hi @Shalane Sheppard good question

I think that a good pattern contains following

testing phase should be contained in the release cycle so you minimize bugs on the production
once the issue is released to the production, you should not reopen it
also the release is released when the artefacts are installed to production -> release is released
if you find a bug on production environment following steps should follow
1. Bug issue is created
2. You can use two fields for Bugs
  1. Affected Version -> is set to version(s) for which you found a bug
  2. Release Version -> is empty and is filled in while the bug fix is release to the production

There is maybe another question "How to solve the bug during release cycle" and there might be tons of answers, but some basic answers came to my mind:

If you are using Kanban and you can release often, you just have to prioritize Bug against your Kanban's features
If you are using Scrum and you are releasing once per 2 weeks (or similar short period), you have to evaluate the bug
1. if it is critical, you should have booked part of your team's velocity for solving these critical bugs and you should fix it ASAP -> release as hotfix version
2. if it is not critical, you should prioritize it and evaluate if you have enough velocity to solve it in the current sprint OR you should plan it to one of the following sprints
if you are using Waterfall you should be in the production already and
1. you have probably some Service contract signed with defined SLAs
2. you should reflect SLAs to the evaluation of the bug and you should fix your bug and release it based on the chosen SLA level

All comments

Martin Bayer _MoroSystems_ s_r_o__

hi @Shalane Sheppard good question

I think that a good pattern contains following

testing phase should be contained in the release cycle so you minimize bugs on the production
once the issue is released to the production, you should not reopen it
also the release is released when the artefacts are installed to production -> release is released
if you find a bug on production environment following steps should follow
1. Bug issue is created
2. You can use two fields for Bugs
  1. Affected Version -> is set to version(s) for which you found a bug
  2. Release Version -> is empty and is filled in while the bug fix is release to the production

There is maybe another question "How to solve the bug during release cycle" and there might be tons of answers, but some basic answers came to my mind:

If you are using Kanban and you can release often, you just have to prioritize Bug against your Kanban's features
If you are using Scrum and you are releasing once per 2 weeks (or similar short period), you have to evaluate the bug
1. if it is critical, you should have booked part of your team's velocity for solving these critical bugs and you should fix it ASAP -> release as hotfix version
2. if it is not critical, you should prioritize it and evaluate if you have enough velocity to solve it in the current sprint OR you should plan it to one of the following sprints
if you are using Waterfall you should be in the production already and
1. you have probably some Service contract signed with defined SLAs
2. you should reflect SLAs to the evaluation of the bug and you should fix your bug and release it based on the chosen SLA level

Shalane Sheppard

This is really great. So do you make the pass and failed step in the workflow closed statuses so you can release the release? In our workflow, we internally pass and fail and then pass it to the client’s team to pass/fail. So I’m wondering where I would make my statuses complete to be able to consider it closed and then I can create the new bug as you mention.

We follow scrum, as you mentioned, scheduled releases every 2 weeks. The affected version field is not currently being used but makes perfect sense.

Martin Bayer _MoroSystems_ s_r_o__

Hi @Shalane Sheppard it is really based on your processes but what we use is following workflow (simplified "completion part" and for development tasks)

...
codereview
testing
ready for release
done

So when developer finishes his task, he moves it to codereview and assigns it to other developer. When codereview is done, it goes to testing phase (it can contain creation of test case + testing + separate handling of bug during testing). When the task is tested successfully, it goes to ready for release. You can mark it with following release version and when it is released you can automatically move the issues to done status.

Main information are

you have developed changes or bugfixes
you tested it
you released (+deployed) changes to PROD environment and tasks are Done

I'm not sure I provided required answer, so just let me know if you need to consult it further...

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud