CODEWITHSUNDEEP
gitgit-flow
Eugene Morozov
Eugene Morozov

Reputation: 15816

Recommended git workflow that allows features to be deployed independently

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)?

Upvotes: 4

Views: 2765

Answers (2)

fabpico
fabpico

Reputation: 2927

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.

Upvotes: 1

VonC
VonC

Reputation: 1324073

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)

Upvotes: 3

Related Questions