CODEWITHSUNDEEP
gitdevelopment-environmentcontinuous-deploymentgit-flowcontinuous-delivery
AXM
AXM

Reputation: 836

Keeping branches in sync with frequent deployments

In my company, we have a requirement to deploy whenever a feature branch is ready to go live - no waiting around. For this purpose, I've came up with with this dev/gitflow process:

Our dev process

The process will work like so:

  1. A developer branches off the "release" branch and works on the feature branch.
  2. While working, the developer can do a local test on dev by merging into it. It is like staging, but QA doesn't touch this environment.
  3. When the developer tests locally and completes work, they merge it into our staging branch and issue a Pull Request into the release branch. [Green line #1]
  4. Once on the staging branch, the staging server automatically gets updated and QA tests on it. [Green line #2]
  5. If QA approves it, they accept the Pull Request and everything that's been tested should now be in the release branch. [Dotted green line]
  6. As soon as the release branch gets a change, we merge it into the master (Production) branch and do a deploy.
  7. My question: After deploying into production, would we merge production back into staging and dev? [Red lines]

My concern is that this process would cause a lot of code conflicts when merging production back downward. Especially if we have stuff on staging that is being moved around from QA -> dev -> QA over and over.

Upvotes: 1

Views: 1736

Answers (1)

Makoto
Makoto

Reputation: 106470

There's a lot of noise in this flow and my concern is that it's overcomplicating what Git Flow nominally accomplishes. My advice in general is to simplify this flow as much as possible - if you need a separate "staging" branch then create it - but in general:

  • Production-ready code lives in master.
  • Developers base work off of master. They can test their feature branch locally, and if they can't, that's something that should be fixed sooner rather than later.
  • Feature branches that require QA testing gets pushed to staging. Ideally, only one feature at a time exists here unless QA agrees to handle more.
  • After staging is tested to satisfaction, then that is merged to master and released into production.

Given that the likelihood of occurrence of multiple feature branches being ready at exactly the same time is rare, simplifying the release cycle in this fashion so that no ambiguity exists with QA (in that it's only ever testing the one feature branch at a time) would simplify things a lot.

Upvotes: 1

Related Questions