GitFlow and Continuous Integration/Delivery

2,489 views
Skip to first unread message

jimit...@gmail.com

unread,
Sep 28, 2011, 8:51:47 AM9/28/11
to gitflo...@googlegroups.com
I'm having trouble seeing how gitflow would work in CI/continuous delivery environment. While you can have your build server target the "develop" branch and build each check-in, the problem is that it's master that actually meant to be delivered to production. 
Lets assume you have the following environments: Integration -> QA -> Staging -> Production and that you're using continuous delivery wherein the "develop" branch (being the bleeding edge) is built and deployed to the Integration environment on every check-in, and subsequently promoted to QA assuming it meets the some arbitrary criteria. QA approve it and promote the build to Staging, where it awaits the next release to Production (or it could be released directly depending on your workflow). At which point would you create the release branch? If on the other hand, you don't release to production every check-in, but accumulate them till "develop" is deemed feature complete, I'd imagine you'd follow the workflow above, keeping Staging up-to-date with the latest changes until it is deemed feature complete, then start an new release (git flow release), fix any bugs that pop up in QA
If on the other hand your build server is tracking "master" where every check-in as a production-ready release, you loose the constant feedback loop on "develop". 
Does anyone have a working continuous delivery setup using this branching model?

Alexander Sorokin

unread,
Sep 28, 2011, 1:02:37 PM9/28/11
to gitflo...@googlegroups.com
Your CI could be tracking develop. Once you CI passes, the features can roll out to QA/staging. That's what we use right now. 
Master should be exactly what's running on the production servers.

Alex

Jimit Ndiaye

unread,
Sep 29, 2011, 3:43:29 AM9/29/11
to gitflo...@googlegroups.com
That was my initial thought too. There are problems with that however. The version number for next production release isn't assigned until a release branch is started. Any bugs found before the release is completed end up in that branch so work on develop can continue, maybe preparing for future releases. This means it is the release branch that would need to be delivered to Integration and QA.
Assuming that happened, while you're testing that release, master and develop could've changed (bug fixes from support/hotfix branches etc). So when you finish the release and merge back into master and develop... You see where I'm going with this? Maybe I've got it all wrong (in which case someone please enlighten me) but it seems a bit more complicated than simply tracking develop.

Jacob Atzen

unread,
Sep 29, 2011, 4:23:51 AM9/29/11
to gitflo...@googlegroups.com
On Thursday, September 29, 2011 at 9:43 AM, Jimit Ndiaye wrote:
That was my initial thought too. There are problems with that however. The version number for next production release isn't assigned until a release branch is started. Any bugs found before the release is completed end up in that branch so work on develop can continue, maybe preparing for future releases. This means it is the release branch that would need to be delivered to Integration and QA.
Assuming that happened, while you're testing that release, master and develop could've changed (bug fixes from support/hotfix branches etc). So when you finish the release and merge back into master and develop... You see where I'm going with this? Maybe I've got it all wrong (in which case someone please enlighten me) but it seems a bit more complicated than simply tracking develop.
Why do you have a master and a develop branch if you're doing continuous deployment? And why do you want to use git-flow?

One way of doing continuous deployment is to only have a master branch and making sure that it is always in a deployable state.

-- 
Cheers,
Jacob Atzen

Jimit Ndiaye

unread,
Sep 29, 2011, 4:43:43 AM9/29/11
to gitflo...@googlegroups.com
We currently have continuous integration and automated deployment but not necessarily continuous deployment. That's what I'm investigating as the next step for us.

Jacob Atzen

unread,
Sep 29, 2011, 5:05:15 AM9/29/11
to gitflo...@googlegroups.com
On Thursday, September 29, 2011 at 10:43 AM, Jimit Ndiaye wrote:
We currently have continuous integration and automated deployment but not necessarily continuous deployment. That's what I'm investigating as the next step for us.
Scott Chacon of GitHub wrote an interesting blog post recently about how GitHub does these things. Perhaps you can find some inspiration in that.


-- 
Cheers,
Jacob Atzen

Michael Ritsema

unread,
Oct 12, 2011, 4:58:17 AM10/12/11
to gitflow-users
You are not alone in realizing there are issues with gitflow and CI.
The problem with having CI pointed to development is that there is a
lot of code that does not get tested. A hotfix come from the master
branch. How do you have your build server suddenly point to these
dynamic branches? Even if you decided to merge to development branch
AFTER you merged into master; development would most likely have new
features that are not a part of the master branch yet.

We use buildbot and as it doesn't support dynamically named branches
that gitflow says to use. I think our solution will be to just use the
'release' branch for releases as well as hot fixes, but this will only
work until we are in a situation where we need to apply a hotfix while
working on a release.

I think the versioning issue you brought up is just one part of the
flaw with this flow and probably not even the worse.

I also am struggling with the issue of how to support maintenance
branches (long term supported deployments).

bnara...@gmail.com

unread,
May 19, 2015, 11:29:39 PM5/19/15
to gitflo...@googlegroups.com, michael...@gmail.com
What about this adapted ones ?

If we have some like  <Dev> = Everyday new features                     -- Will have new features   
                                <Test Ready> = Dev + Merges from Master    -- This would support hot fixes and for Test candidate release 
                                <Master> = Production                                  -- Production 
any thoughts on the above

Regards 
Reply all
Reply to author
Forward
0 new messages