Managing releases question

We currently use Jira as our ticketing system with the following workflow:
New - Ticket created
In Progress - Developer working on ticket
Resolved - Developer fixed or implemented new feature
Built on Dev - Developer released code for testing and does a pull merge request into our release number on Github ex. 2.0 from their forked branch
Testing - QA testing if everything is fine then it changes to Ready for Deployment
Ready for Deployment - Ready for deployment
Deployed - Code is deployed to production

The person in charge of releases then takes all code from release number and does a pull request into master which then gets released to production.

We are facing the following problem. If a ticket is not ready for release, it is a lot of work for the release person to cherry-pick or remove the not ready code. They could miss something when trying to find all the code that is not ready and have headaches on production because the wrong code got released.

If a developer did 10 commits for the same issue then I could see it being missed.

Any suggestions on how to improve this process?


Hi @maxillosoft-dimitry,

What sort of branching strategy do you use for managing your code? Do you use the GitHub Flow or Atlassian’s Gitflow Workflow to manage when code is added to the project?

1 Like

Sorry for the delay.

I thought these strategies are almost the same, feature branches flow, the only difference is that branch off new feature branch from develop or master branches.

We use closer to Atlassian strategy.


Hi @maxillosoft-dimitry, you are correct, those branching strategies are very similar. Some people don’t use any strategy at all, so I wanted to confirm that you were using a branching strategy to begin with.

If you’re using different branches for each feature and only merging them into the production branch once the feature is complete, this should prevent the need for cherry-picking code. If you’re having issues while still using a branching strategy similar to the Atlassian branching strategy, my first recommendation would be to see if your developers can break down these changes into even smaller chunks. For instance, if you’re currently using one branch for each developer, maybe change it so that you use a single branch for each Jira issue.

Is that helpful in your current situation or are you facing a different issue?

Thanks for responding so quickly.

The problem we are facing is the developers have their own branch and then merge into a build branch for the QA team. We have one machine/site for testing and the whole QA team is using this machine/site for testing. If that issue is working then the QA team changes the status to Ready for Deployment and we are fine but if there is a problem then they change to reopen.

The developers will then work on the problem again and put in there commits on the build branch for QA team. If the issue is still not resolved, then it goes back to the developer.

The problem arises when one issue is not fixed and has a lot of commits associated with it. The deployment developer has a difficult time trying to cherry-pick all the commits into the master branch and it becomes a nightmare so we end up having to wait until that issue is resolved before we can do a release.

After trying to brainstorm this problem with the developers, I heard the following:
1)If we have separate machines/branches for each developer then when we merge everything together it will not be fully tested and this is a problem. Also there could be conflicts and then the deployment developer is wasting time trying to resolve all of them.

2)If I cherry-pick all the commits then I could miss something and the release will fail.

I hope everything I wrote made sense. It is difficult to describe.


Would it be possible for the QA team to test from a temporary merge branch? As in:

  • take the current QA build branch
  • create a temporary branch from there
  • merge the developer branch
  • test
  • if the test passes, ff-merge into the QA build branch

That way the feature can be tested in its merged state, but it’s easy to discard the merge if tests fail.

Multiple developers would be merging into that branch so I am not sure how that would be any different. They would merge into temporary branch and then someone would have to merge into QA build branch.

I am trying to figure out an option that the developers told me is not possible with github but it is hard for me to believe that github would not have this option.

Please correct me if I am wrong in my understanding:
Developer would commit to a branch and would label that commit with a tag or something. Ex. Ticket 123.
Lets say the developer had that ticket returned and they made some more changes and did another commit and label it again with tag or something. Ex. Ticket 123
At the same time other developers are committing their tickets with labels such as Ticket 234, Ticket 456, Ticket 678.

If ticket 123 is not ready, the deployment developer can cherry-pick all the tickets except Ticket 123 by tag or label without have to cherry-pick each separate commit. Is that possible?


My proposal would be to avoid exactly that. Have the QA team create that temporary merge for each branch that should be merged. If the branch is good, do the real merge, if not, just discard the temporary branch. Nothing untested ever makes it further. It’s more work for QA (because they need to do more more rounds of testing), but it avoids any untangling later.