4

In our organization we're currently using the following flow.enter image description here

Feature branch is forked from the production branch. Feature is implemented in the feature branch on the developer machine. Then feature branch is merged into develop branch which is automatically deployed on staging server.

The feature is tested by users on the staging server and if the business decides that it is good and that it is time to deploy it on live server, feature branch is merged second time, this time into the production branch which is deployed on the production server then.

But some features are abandoned for various reasons. For example, business decides that it's not yet time to deploy the feature to the live server. Or maybe it's no longer required. Or maybe we'll return to it one year later. On my picture the feature/1 is never merged into production branch but is merged into develop branch.

This means that develop branch diverge more and more from the production branch. Note that develop is never merged to production (in the canonical git flow, develop is merged to production by using release branches).

In my opinion this workflow requires a lot of manual labor. Because production and develop are different, manual merge is required when the feature branch is merged to develop for testing. This is also error-prone because we have old unused code from feature branches in develop that is never going away. Not only it makes merges complicated, but it also means that feature branch code may work differently in the develop and production branches because the old unmerged code can affect the feature code.

Also, I have a feeling that with every new feature this will make the work more and more complicated because amount of differences between develop and production will inevitably grow. There's no point in flow where develop and production are reconciled, so I'm afraid that one year later and maybe 10,000+ commits later the merges will become simply too complex to handle. Even now we have merge bugs. Some are evident, some are subtle and very hard to find.

I've raised the question several times to CTO that this flow is inherently inefficient and error-prone. But he insists that this flow is optimal because it allows business to choose when features are deployed to production. Also, he claims that he had used exactly the same flow at previous jobs in big companies.

I also have a lot of experience but I never had seen such flow and I never read about such flow in a book or blog article.

I have two questions:

  1. Is such flow (where develop and production are constantly diverging) indeed used in big teams?
  2. If I'm right that it is suboptimal at best, what is the best way to persuade the CTO to migrate to a better flow (for example, canonical git flow)?
Eugene Morozov
  • 15,081
  • 3
  • 25
  • 32
  • 1
    Feature flags are a good solution to this type of issue. Development continues unhampered, and the product team can decide when (and if!) features are turned on/off. – CollinD Aug 09 '18 at 03:27
  • Doesn't help because I've already suggested it and got the same response: "The flow is good, you just don't like it". I'm looking for some strong argument. Or maybe confirmation that I'm wrong and this flow is good. – Eugene Morozov Aug 09 '18 at 03:29
  • 1
    Sounds like you're free to move on and not worry about it. It's someone else's job and if they don't have issue with it, no reason to try to make it yours. Just my opinion. I agree though. Any flow that involves constant merge conflicts is probably garbage. – CollinD Aug 09 '18 at 03:30
  • Maybe I'm missing something, but what is the point of the `develop` branch, if it never communicates back with either a feature or production? – Tim Biegeleisen Aug 09 '18 at 03:30
  • It's my job to do the merges and solve the problems created by merges and bugs caused by the code behaving differently in different branches. I hate merges and they're becoming more and more complex, just like the interactions of the code when it's merged into `develop` branch. I have to deal with this daily. – Eugene Morozov Aug 09 '18 at 03:31
  • @TimBiegeleisen `develop` exists solely for the purpose of deploying it to the staging server where users (business) can test it and approve or reject the feature. – Eugene Morozov Aug 09 '18 at 03:33
  • What is the mechanism by which features etc. get merged/introduced back into production? There must be a merge happening somewhere, though I don't really see it in your diagram. – Tim Biegeleisen Aug 09 '18 at 03:34
  • @TimBiegeleisen `feature/2` is merged to production. This is a diagram of branches and merges, so it looks like it is merged simultaneously to `develop` and `production`. But in reality it is first merged into `develop`, tested, and then merged into `production`. – Eugene Morozov Aug 09 '18 at 03:36
  • 1
    So let's say that a feature were merged into develop which ended up _not_ being merged back into production. Then, wouldn't develop still have that unwanted feature in it? I agree that your Git workflow should be changed +1. – Tim Biegeleisen Aug 09 '18 at 03:40
  • 1
    @TimBiegeleisen Yes, this is exactly why I consider this to be a problem that only will get worse over the time. But I can't convey this to the CTO. Maybe because English is not my first language. Maybe because of some other reason. – Eugene Morozov Aug 09 '18 at 03:42
  • Wow. This question's workflow is unfortunate. Being 2+ years later were you able to convince them why this is a problem? If no, I can only imagine what `develop` must look like now. The key here is that your workflow's `develop` *should* be a throwaway branch that's reset regularly. In my organization we use Git Flow with a gitworkflow attached, so that the feature branches are all validated prior to merging into `develop`. We reset our `next` branch to be the same as `develop` every Sunday. I bring this up simply to point out that Git Flow and gitworkflow are compatible with each other. – TTT Apr 09 '21 at 19:39

2 Answers2

3

The best workflow to integrate or remove feature branches at will in an integration and then master branch is:

gitworflow (presented originally in 2017 with "Handle git branching for test and production")

It is the one used for the repo Git itself.
Its characteristics:

  • It resets the staging/dev/testing branches at each new release cycle, making those branches ephemeral (ie destroyed/recreated)
  • it merges the feature branches to those branches (instead of merging from dev to test to staging)
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

I ran in to the exact same issue, at some point its a mess to deal with such diverged develop/production branches.

The problem is the business, that suddenly decides that a feature does not come into the next release, or the business just does not take the time to test the feature. And this is not a problem that any git flow should solve.

gitworkflow may try to solve this problem, but its very complicated, as they also say by them self:

Gitworkfow is more complicated, and harder to understand than most (probably all) other flows. It requires more understanding of git concepts and capabilities. It offers significant powerful capabilities to complex multi-dimensional products with a team of developers, but does have more "overhead" in the sense of multiple things to track and understand.

So i suggest to simply use git-flow which forces to release all code from the develop branch, instead of only specific features from the develop branch. If a feature then should not yet be used in production, just implement a feature toggle.

fabpico
  • 2,628
  • 4
  • 26
  • 43