4

Requirements

  • We have got 2 environments. -- Test and Prod
  • We want to do Continuous Deployment.
  • We are using Git Flow.

With git-flow we are supposed to deploy the release (or master) branch in production. ( two different pipelines,one for continuous integration (branch develop) and one for continuous delivery (branch master).

How should I use my release branch ?

What I have in mind is if the tests pass in develop. I would make the CI server create a release branch commit. And deploy the updated release branch points to my productions staging slot. After business approval one of the release points would get deployed to production.

This means I am letting CI server automatically create a release-branch and re-run all the tests on staging slots of production environment. If it fails, it will report and delete the release branch, otherwise it will create the release point,trigger network swap and merge it to master.

What is the pros and cons to this approach ? What is the best practice ?

Do we really need the release branch especially where we are not using feature toggles to separate releases ? ( there are multiple people working on the same project )

enter image description here enter image description here][2

Reference

Rıfat Erdem Sahin
  • 1,738
  • 4
  • 29
  • 47

2 Answers2

2

Typically I would create/cut a release branch when you think the code is close enough to stable. Then you need to refine that branch until it's release-ready. You would do extensive regression testing after this and then finally tag it and release it.

If you're doing true continuous releases then you might be skipping a lot of that testing so there isn't really a big point in even having a release branch. It's a lot riskier but you can do it if it fits your model.

Joe Phillips
  • 49,743
  • 32
  • 103
  • 159
  • "create/cut a release branch" meaning CI creating the release points in release branch ??? – Rıfat Erdem Sahin Jun 09 '17 at 08:49
  • @RıfatErdemSahin Creating an actual branch. After the branch is "ready", you might merge it into 'master' which could kick off an automated deploy or something – Joe Phillips Jun 09 '17 at 12:50
  • thanks for the response. My Plan : Thinking the release branches kick of deployments in staging. Where the master branches will kick of a network swap from the well tested staging environment. – Rıfat Erdem Sahin Jun 09 '17 at 13:07
2

git-flow says about release branches:

Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.

If your group's workflow doesn't match the use case for release branches, don't use them. If you find you need them later, start using them.

We use git-flow in one of the groups where I work. Often we only have one or maybe two developers working on a project doing maintenance, and it's rare that we need to simultaneously bug fix and add features. We don't use release branches unless we have that specific scenario.

Overall I like the pipelines you're setting up.

bluescores
  • 4,437
  • 1
  • 20
  • 34
  • Release branches support preparation of a new production release. >>> Agreed. The business people might not want to go live with all the release points. Some would make sense and some would not make sense. ( There could be a marketing campaign which would require timing ) – Rıfat Erdem Sahin Jun 09 '17 at 08:36