1

We have a Gitflow/trunk-style source control system in Git, where releases go through the following process:

  1. Devs branch off master
  2. Devs pull request into master
  3. After PR merged, build happens to "QA" environment
  4. QA team tests code
  5. We do a release from master(devs PR's to master, we do some testing, then we do a release from there).

Now, a given 'build' to QA might have a few chunks of work. Problem is, if an issue is found at step 4) above, we only have the following options:

  1. Fix the code (slow)
  2. Go to production with the issue (risk)

Basically, one bad 'chunk' of work means other good work can't go to production.

How can we fix this?

These are my ideas, in terms of my preference:

  1. Use a 'release' pipeline, like this: enter image description here Means that each commit goes through a set of stages. If a 'new' piece of work doesn't pass a stage, it doesn't get promoted. In other words we can release from the 'last known good build'. Can use something like Octopus Deploy for this.
  2. Use 'release' branches in Git. After something is tested, we move it to a 'release' branch.
  3. Cherry-pick good commits in Git. Kind of similar to 2.

Any suggestions? What's the best practices here to solving this problem?

RPM1984
  • 72,246
  • 58
  • 225
  • 350

1 Answers1

0

Basically, one bad 'chunk' of work means other good work can't go to production.

That is what I describe in "Handle git branching for test and production"

in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts.
Gitworkflow allows both goals to be achieved without sacrificing one for the other.

(Gitworkflow is described in more details in rocketraman/gitworkflow)

In your case, you should use an ephemeral QA/integration branch first, running the test, and update master if those test pass (and trigger the release into production)

"ephemeral" means: you create/reset the QA branch just for integrating the feature branches marked as being for the next release.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I _think_ i understand, but let me try and summarize. 1) devs branch off master (e.g `feature/xyz`). 2) when ready for testing, they get someone to test their branch. 3) when testing passes, they merge to `master`. 4) we do a build on `master`. That basically it? If so, my concern is what about testing all the work 'together'? There is no QA for that? So you either test _once_ in isolation or twice (isolation + integration)? OctopusDeploy seems easier.. they basically keep those 'branches' as artifacts you can test/move between. – RPM1984 Jun 01 '18 at 00:27
  • is there a diagram somewhere? might be easier for me/others to understand.. – RPM1984 Jun 01 '18 at 00:27
  • @RPM1984 the integration (merge of topic branches) is done on next, not on master: see the last diagram of https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb (http://jsfiddle.net/jtooun5q/5/) – VonC Jun 01 '18 at 03:54
  • yeah, i see now. Wondering if it's a bit complicated for a team not well versed in git? Isn't OctopusDeploy/release managers also giving us the same flexibility? Each piece of work can 'graduate' to a next stage (e.g environment), and if something isn't good, we don't gradudate it.. we graduate the previous one. Seems like the same end result, but we can do it via a release mgmt tool, rather than Git? Just trying to find the easiest solution for the team. – RPM1984 Jun 01 '18 at 06:37
  • @RPM1984 I agree, this is more comple in that there is not (to my knowledge) a neat wrapper around that process. But it is the more flexible, allowing you to graduate/reject topic branch at will. This differ from OctopusDeploy/release which is about release management (of the built artifacts), not about source control. – VonC Jun 01 '18 at 07:05
  • you're right. In the OD/release way, the 'source code' is still unstable, you're just getting the flexibility to choose which releases to push forward with. So i guess you need to choose from stable source code vs release flexibility (or both, in the gitworkflow case) – RPM1984 Jun 03 '18 at 23:27