not quite sure how to put that into the title, because the issue is a bit specific.
Basically, we're using
gitflow (slight variation of it) in our application. So, this means we have the following branches
- master (PROD)
- uat (STAGING)
- dev (TEST/QA)
We create all our features from
dev. The developer creates a PR for their feature branch
dev. Once it's merged into
dev, the changes are deployed to
At the end of every sprint, we deploy from
uat to put the changes onto the
staging server. The
staging server is actively tested by many people, that's why we have a specific day in the sprint for deploying where it's expected that maintenance happens.
Now the issue is the following. Let's say, 1 day before the sprint ends and we do the deployment, a feature has been merged onto
dev, because code review and local teseting were fine.
However, QA found a small issue or maybe didn't have the time to test it yet.
When we now deploy to
uat by creating
release-branch off of
dev we would also push the changes that aren't QA Done yet onto UAT. This is of course an issue.
I'm wondering how we can cancel out this issue? I have multiple thoughts
- Put a lock on
devone day before the sprint, so that nobody can merge anything to dev anymore when we see all tickets are QA done. However, we would lose one day of development with that, because if on that day we would finish sth. if wouldn't get deployed
- Revert the merge commits of those that should not be deployed, but this feels like a workaround
- Create release branch off uat and cherry pick the merge commits, but tbh, I don't like using cherry-pick for such a case as it just applies the diff again instead of the commit itself
- Only deploy to
devwhen QA has approved the task before. That way, there is only one feature on
devand we will only merge another if it's QA done, however, this works only if we have 1 qa employee. If there's 2, then what would the other test? Also, we would get a pile of open pull requests that are basically ready, but not merged and then we always have to keep that in mind and it could still happen that the last feature that was merged will not get QA done state until release starts
- Last option would be a release based on feature branch. And only if the feature branch release is successful we merge it into dev and then we can really create pr from dev -> uat and only the changes that have to be in there are deployed. However, we have a microservice architecture and are 5-6 teams. If we would create extra infrastructure for this case it would be super expensive if we want to deploy muiltiple at the same time.
So I don't know the best way. I just knoow that we have issues every release day that we are not sure if we can deploy, if QA will get it done, if QA will have findings and the deployment day is always super stressful