Timeline for Where to tag releases to achieve "build-once, deploy-everywhere" using GitFlow?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 27, 2023 at 17:46 | comment | added | Ben Cottrell |
Also keep in mind the focus of GitFlow is the develop branch - so there would be frequent merging into that branch, and ideally plenty of integration testing here, but creating a release (tag) by merging from develop into master would only occur once per release cycle (e.g. a team working with monthly releases would do this merge once per month. Once QA starts, any hotfixes for that release go into the release branch, before eventually delivering that release into production -- but the final delivery might not happen until the very end of the release cycle - e.g. a month later.
|
|
| Dec 27, 2023 at 17:16 | comment | added | Ben Cottrell | @KurtBourbaki I think you are reading too much into terminology that has evolved a great deal in 13 years. No matter how it is worded, The authors of gitflow didn't intend that every merge back into master would be ready to be deployed into its production environment. Just to re-iterate from my earlier comment ,a "release" in Git-flow isn't a release artefact, it's really nothing more than a version tag on master (i.e. a version which doesn't contain pre-release identifiers). It's not a suggestion about about the state of the code - i.e. not a tested, production-ready artefact. | |
| Dec 23, 2023 at 11:08 | comment | added | Kurt Bourbaki | @BenCottrell as far as I read in the original GitFlow document, "[...] each time when changes are merged back into master, this is a new production release by definition". QA is not mentioned anywhere in the document (nvie.com/posts/a-successful-git-branching-model) | |
| Dec 19, 2023 at 15:02 | comment | added | Ben Cottrell | @KurtBourbaki I mentioned it as Continuous Delivery was a relatively uncommon practice back in 2010 when the article about git-flow first appeared. A prerequisite for CD is that changes are fully tested before merging, so every merge into main/master should be production ready (Which I believe is what you're after here). The people who developed Git-flow did not practice CD at all -- their concept of a 'release' merely refers to the existence of a version tag from which an artefact could be published into QA ready for testing; it's not an expectation of production readiness. | |
| Dec 18, 2023 at 16:57 | vote | accept | Kurt Bourbaki | ||
| Dec 18, 2023 at 14:02 | comment | added | Kurt Bourbaki |
Thank you @BenCottrell. I work in a regulated environment and we must follow compliance rules, so each release has to be well-defined. That is why GitFlow seems like a better candidate compared to, say, Github Flow. I'm not sure why you mention CD though. GitFlow states that each commit on master is a release. What I want to do is just reuse (in prod) the same build that has already been tested on the QA environment. Why does it involve CD? Could you elaborate?
|
|
| Dec 17, 2023 at 21:28 | comment | added | amon | Note the update at the top of the nvie article: "This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow". You can usually drop the right half of that diagram. There are no release branches. Hotfixes are just prioritized features. The develop branch is always deployable. Tags can be useful for keeping track of what was actually deployed/released. Instead of explicit version numbers, you might just use Git commit IDs. | |
| Dec 17, 2023 at 15:56 | answer | added | Ewan | timeline score: -1 | |
| Dec 17, 2023 at 14:40 | answer | added | Thomas Owens♦ | timeline score: 5 | |
| Dec 17, 2023 at 14:18 | comment | added | Ben Cottrell | I would take a step back and start by capturing what your needs are from a branching strategy - ideally starting out with something as minimal and light-weight as possible. The added complexity of git-flow brings a raft of disadvantages unless you really need it - georgestocker.com/2020/03/04/please-stop-recommending-git-flow | |
| Dec 17, 2023 at 14:13 | comment | added | Ben Cottrell | I'd like to highlight the notice at the top of the article which tries to point out that git-flow is often not a good fit. Git-flow is not intended for the Continuous Delivery (CD) mode of release that you seem to be after here; quite the opposite - it is designed for longer release cycles where multiple concurrent release versions need to be supported. With git-flow an artefact is fully tested after a release cut has been taken. Issues discovered in QA are "fixed forward" using hotfixes, applied to the release branch (subsequent hotfix releases are cut from the release branch). | |
| S Dec 17, 2023 at 10:47 | review | First questions | |||
| Dec 17, 2023 at 15:07 | |||||
| S Dec 17, 2023 at 10:47 | history | asked | Kurt Bourbaki | CC BY-SA 4.0 |