Git workflow for beta/production

Git workflow for beta/production

[Joseph Huttner]

I am in search of a new Git workflow.  Previously, my team was essentially using using gitflow by Vincent Driessen (nvie).  It worked very well, but the needs of project have changed, so here are the new requirements:

1.  A "Beta" environment that contains stable code for all features being considered for "Production."
2.  A "Production" environment.  Rock-solid, well-tested code only.  

The catch is that after a feature has been stomped on in Beta, it **may** go to Production, but only if Product Managers still think it is an important feature.  In other words, there is no guarantee that a feature in Beta will ever make it to Production.  It may be axed completely, in which case it would never get to Production and would be taken out of Beta.  Also, there is no guarantee that features that do make it to Production will go in in the order that they went in to Beta.  

A few notes that may matter:

a) Six developers on team and growing.  Will be 9 by the summer.
b) Codebase is 110K in-house lines.
c) Typically, a feature is worked on by 1-3 developers at a time.  Total development work on a feature can be anywhere from two hours to two months.  The median is about two weeks.
d) Currently, per week, about 15 bug reports come in for today's equivalent of the Beta branch.

Ideally, using the new workflow, releases to Beta would be a few times per week.  Releases to Production would be once per month.  This is the same as our current release cycle.

I have been on the whiteboard trying to think about a Git workflow that suits my needs, but my head is spinning, which is a signal to me that I need help from more seasoned vets.  Any and all help is appreciated.

-Joseph

Re: Git workflow for beta/production

[Randal L. Schwartz]

>>>>> "Joseph" == Joseph Huttner <jhuttner@appnexus.com> writes:

Joseph> The catch is that after a feature has been stomped on in Beta,
Joseph> it **may** go to Production, but only if Product Managers still
Joseph> think it is an important feature.  In other words, there is no
Joseph> guarantee that a feature in Beta will ever make it to
Joseph> Production.  It may be axed completely, in which case it would
Joseph> never get to Production and would be taken out of Beta.  Also,
Joseph> there is no guarantee that features that do make it to
Joseph> Production will go in in the order that they went in to Beta.

Sounds like you want the same sort of workflow that git itself uses,
with topic branches.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Git workflow for beta/production

[Junio C Hamano]

Joseph Huttner <jhuttner@appnexus.com> writes:

> I am in search of a new Git workflow.  Previously, my team was
> essentially using using gitflow by Vincent Driessen (nvie).  It worked
> very well, but the needs of project have changed, so here are the new
> requirements:
>
> 1.  A "Beta" environment that contains stable code for all features
> being considered for "Production."
> 2.  A "Production" environment.  Rock-solid, well-tested code only.  
>
> The catch is that after a feature has been stomped on in Beta, it
> **may** go to Production, but only if Product Managers still think it is
> an important feature.  In other words, there is no guarantee that a
> feature in Beta will ever make it to Production.  It may be axed
> completely, in which case it would never get to Production and would be
> taken out of Beta.  Also, there is no guarantee that features that do
> make it to Production will go in in the order that they went in to Beta.

Is it just me, or does the above sound exactly like how git itself is
managed, when "Beta" and "Production" are read as "next" and "master"?

> A few notes that may matter:
>
> a) Six developers on team and growing.  Will be 9 by the summer.

120 active developers on team for the last 6 months, among which 35 people
have more than 5 commits.

> b) Codebase is 110K in-house lines.

157k lines counting only '*.[ch]' files.

> c) Typically, a feature is worked on by 1-3 developers at a time.  Total
> development work on a feature can be anywhere from two hours to two
> months.  The median is about two weeks.

Quite similar.

> d) Currently, per week, about 15 bug reports come in for today's
> equivalent of the Beta branch.

Git being a volunteer project it is probably harder to compare; we have
busy weeks and quiet weeks.  For the past 6 months, I count 230 merges to
the 'mater' that merges fully cooked topics, so that is roughly 8-9 topics
a week.

> Ideally, using the new workflow, releases to Beta would be a few times
> per week.  Releases to Production would be once per month.  This is the
> same as our current release cycle.

I do merges to 'next' roughly once per day (sometimes twice a day,
sometimes once every other day), and 'master' roughly twice a week.

All of the above makes me suspect that imitating what I do and other
people work with me might be one possible approach.

Re: Git workflow for beta/production

[Drew Northup]

On Mon, 2011-03-14 at 15:27 -0700, Joseph Huttner wrote:
> I am in search of a new Git workflow.  Previously, my team was
> essentially using using gitflow by Vincent Driessen (nvie).  It worked
> very well, but the needs of project have changed, so here are the new
> requirements:
> 
> 1.  A "Beta" environment that contains stable code for all features
> being considered for "Production."
> 2.  A "Production" environment.  Rock-solid, well-tested code only.  
> 
> The catch is that after a feature has been stomped on in Beta, it
> **may** go to Production, but only if Product Managers still think it
> is an important feature.  In other words, there is no guarantee that a
> feature in Beta will ever make it to Production.  It may be axed
> completely, in which case it would never get to Production and would
> be taken out of Beta.  Also, there is no guarantee that features that
> do make it to Production will go in in the order that they went in to
> Beta.  

Hi Joseph,
First off, don't discard the baby with the bathwater. If Nvie's workflow
was working for you don't discard it completely and outright--that's
just asking for problems. Second, don't be afraid to be aggressive about
rewinding your "beta" branch (as noted that's "next" around here at
git.git, but "pu" might be an even better model).
It sounds to me as if just one additional "branch family"--a "customer"
beta--could be added to Nvie's base structure to accomplish what you
need. The policy on this new track would be to expect it to be
rewound/rebased/restructured frequently. From there whole features would
be picked out (per management decision) and put into the equivalent of
the "[proposed] release" branches and whole public releases pushed from
there to master ("release" would therefore also be rewound as
needed--hopefully not very often) for packaging. The major change in
code flow is that things no longer migrate back from "release" to
"development" (bleeding-edge), "beta" (aka a "customer beta"--which is
what your management team seems to be asking for), or anywhere other
than master--basically making "release" a clean-room version of beta
with no new code in it.
I would not advise outright discarding of any "hotfixes" branch you
have, I would just make it merge to master only via "beta" and "release"
except in cases of emergency. Let the management team decide what
qualifies as that kind of emergency.

Why continue to have the "release" branch at all? Well, it sounds to me
as if you are being asked to make absolutely certain that what makes it
to master (and therefore what makes it to your packagers) is tested as a
whole unit. You can't do that cherry-picking directly from beta to
master (customer production code). Having the "clean-room" post-beta
"rc" branch gives you a safe place to do this--good for cases when
somebody insists on including "feature y" from the customer beta without
also including "feature x" forgetting that y depends on x to build or
run properly. This should have all been hashed out in beta--but that's
harder to do when beta is considered to be a "new feature customer demo"
branch as well as "beta" branch. So, the moral of the story is roll
stuff into a safe place after the "feature demo" beta for approval and
unit testing before pushing to master and risking causing confusion in
the ranks of the packaging team. (It is never good when a customer hears
that a vendor didn't mean for them to be sent version n.xx of the
production code but instead meant to send them n.xy.)

Good luck!

-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59