0

We use gitflow branching strategy for different reasons, one of them being complicated bureaucracy around releases.

We have environments: dev, qa, preprod, prod.

Once the developers finish their work in dev branch, we create release branch and trigger deployment to qa. After qa process is done, we trigger deployment of the same branch to preprod. After tests in preprod are finished, we deploy the same branch to prod.

Issues arise when business asks to remove/add some features from release branch, for example, after deploying to preprod but before deploying to prod. In that case, if its a simple commit or several of them, we can cherry-pick. But that gets complicated very soon.

Is there a general solution for this? And, is the solution technical or is it on the planning side like establishing a consensus: release branch doesn't get deployed to production until all the features that went into release branch initially are ready?

Improve this question

2 Answers 2

Reset to default
1

If you need to remove features from something that has been deployed to preprod, the new code should go through the process of promotion from dev to qa to preprod before it reaches prod. Depending on your amount and quality of automated testing, this could be a very fast process, but it doesn't make sense to short-circuit the process and put potentially untested or undertested changes into production.

In the absence of something like feature flags or keystone interfaces, Levi's suggestion of feature branches and squashing merges to make it easier to revert all aspects of a change is good. However, it doesn't negate the need for good testing since later changes could rely on the earlier (now-reverted) change. However, I would also invest time in understanding the root causes for needing to revert the change in the first place and addressing those so this becomes an exceptional case.

Improve this answer
7
  • When you say invest time to understand the root causes... do you have things like "too little time to test appropriately" or "underestimates time for development" on mind? or something completely different? PS. feature flags & keystone interfaces are very nice hint here!
    – tlt
    Commented Nov 28, 2023 at 13:07
  • @dzg I don't know what your root causes could be. There are techniques, such as using five whys or Ishikawa diagrams or causal graphs to understand why you had to revert the changes. Creating a value stream map could also be beneficial. Unfortunately, without a much deeper understanding of your process, I couldn't assess potential problems or causes for needing to revert changes late in the development process.
    – Thomas Owens
    Commented Nov 28, 2023 at 14:05
  • Yeah, I see. That make sense. Btw, does the same line of thinking like in your answer stand for the case when there happen to be 2 competing releases? For example, it took longed than expected to test one release in preprod while other is ready to go to qa. Does in that case 1st release branch gets invalidated and new one created with both change sets going again through qa > preprod > prod cycle?
    – tlt
    Commented Nov 29, 2023 at 18:07
  • 1
    @dzg That depends on why you have two competing releases. If you have different production environments, then you should have parallel qa and preprod environments as well. If you have a single production environment, If you have a single production environment, I would want to focus on reducing the time to test in each environment and getting to a series of releases. I'd really need to dig into why you're finding an issue in preprod if it got through dev and qa activities, as well.
    – Thomas Owens
    Commented Nov 29, 2023 at 18:31
  • 1
    @dzg These are not technical problems, so you won't find technical solutions to them. For example, setting strict release dates. Assuming a fixed team, you need to make either scope or quality flexible. Technical practices may help slightly, but won't fix root causes.
    – Thomas Owens
    Commented Nov 29, 2023 at 18:50
1

Have your developers do their work in feature branches and do a single feature per branch. Then merge their work into your dev branch. Now when you need to drop a feature from your release branch it's easier. If you want to make it really easy, when you merge from a feature branch to dev use the squash setting.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.