Thread (1 message) 1 message, 1 author, 2016-06-15

Re: Git workflow for beta/production

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:46

Joseph Huttner [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help