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?

tlzg
  • 103
  • 3

2 Answers2

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.

Levi
  • 1,044
  • 6
  • 18
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.

Thomas Owens
  • 333
  • 1
  • 8
  • 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! – tlzg Nov 28 '23 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 Nov 28 '23 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? – tlzg Nov 29 '23 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 Nov 29 '23 at 18:31
  • yeah, its web app and its a single production environment. I would say all of the problems stem from less-than-ideal planning. For example: release dates are set strict without taking into account ETAs from developers enough, time planned for testing was too short so it turned out that QA didn't pick all of the problems and then preprod feedback>hotfix cycle took more than expected. Its that kind of stuff. And sure, that's what needs to be fixed but what I am looking into is what are the technical ways not to solve but to absorb at least some of those issues. If that makes sense. – tlzg Nov 29 '23 at 18:37
  • 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 Nov 29 '23 at 18:50
  • yes, i am completely aware of that and all of this is trying to find ways to "make things slightly better and help slightly". – tlzg Nov 29 '23 at 19:10