Need feedback on proposed git flow

Question

We just migrated to git from svn and are trying to define a process that would help us achieve the following:

1. Deployment to dev env without requiring code review.
2. Have a pull request / code review process when merging into the release branch.

Environment:

1. We have a team of 3 developers.
2. There are 3 envs - Dev, Test and Prod.

Proposed Process:

1. We have 3 git branches.

   • dev: Used to merge all features and deploy to Dev env.
   • release: Used to merge all features and deploy to Test and Prod envs
   • master: Merged from release

2. Developers work on individual feature branches off created off dev branch

3. Developers cannot test their changes locally and hence are required to move their code to Dev env to test. So they merge their changes into the dev branch when they want to test.

4. There are frequent such merges to dev branch from different feature branches as everyone tests out their features and fix the bugs.

5. A week before prod release date, developers create Pull requests to merge individual features into the Release branch for features which are ready to go live to Prod.

6. Their pull requests will be reviewed by peers and merged into the release branch.

7. After all PR are merged, the artifact is tested by QA team in Test env.

8. Assuming all is well this artifact will be deployed to Prod and the release branch will be merged into master. Marking end of release

I would like to get feedback on the proposed process. Also I have below concerns around this process: In point 6 of Proposed process - would developers need to rebase / merge their feature branches with release branch and again push the changes in the feature branch in order to be able to merge? And would it matter in what order the peers review each feature branch and merge into the release branch?

Answer 1

Developers cannot test their changes locally

This is a gigantic problem, all your other issues stem from this problem and it should be your top priority to solve this. How you solve this will depend heavily on your set up and is worth a separate question. Therefore everything else I'm going to say is irrelevant, but:

I think you have a nasty mix of git flow and Trunk based development, git flow basically isn't going to work for you with the "can't test locally" problem.

Developers work on individual feature branches off created off dev branch

This is a problem*, this means my branch for feature A contains all the in progress work of everyone else's, none of which has been code reviewed. This means when I put in a pull request it contains everyone else's unfinished work which must then all be reviewed together. Your work shouldn't be branched off any branch that hasn't been code reviewed [Exceptions of course apply, but as a general rule]

*Other workflows may do this with a branch called dev and be fine, but in this case dev is a branch that just contains a grab bag of everyone in-progress stuff.

Developers cannot test their changes locally and hence are required to move their code to Dev env to test. So they merge their changes into the dev branch when they want to test.

Fix this, the whole process will be broken while this is the case

A week before prod release date, developers create Pull requests to merge individual features into the Release branch for features which are ready to go live to Prod.

I'm assuming you mean "At least a week before .." not "A week before ...". Completed work should be code reviewed and merged as soon as possible. Having many feature branches hanging around just leads to merge conflicts.

After all PR are merged, the artifact is tested by QA team in Test env.

This is a bit waterfall but not fatal. Ideally the features should be tested as soon as they are finished, so that when bugs are found people still remember what all the pieces were supposed to do

Summary

All that said, what you effectively have is "Everyone commits directly to master and code reviews happen on a per commit basis after the fact, release branches taken for release to prod" but with extra steps (like calling master dev, branching in and out of dev for no reason and merging from your branch that contains all of dev into a release branch). If you're going to effectively do that, just do that. [I personally don't like that, but for a small team like you have it can work].

Answer 2

It would be worthwhile to have feature branches testable on the server, just like dev branch is testable in your proposed setup. With only 3 developers, this won't be an unsustainable multiplication of testing environments; you could probably force Jenkins or whatever CI you use to reuse same testing environment for all feature branches (this would mean that developers will not be able to test their changes in parallel, but that's what you already have if they all have to merge to dev branch).

Having performed tests, a developer would start a pull request to dev branch. In the ideal world, such PR would automatically trigger an automated test, but waiting for code review won't delay further development, possibly of a different feature, likely branched from the dev branch.

Sometimes, new feature branch will continue from a pending-on-code-review feature branch. This may require an extra merge to the new feature branch when the PR gets finally accepted, but it should not be a terrible merge.

At any rate, the feature branch must get merge from the dev branch every time the latter is advanced (one of its pending PRs getting accepted). If a PR lingers for a long time, this can get painful. But if the PR is marked WIP, work in progress, it can afford to be not up-to-date vis-a-vis the dev branch.