git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git workflow for beta/production

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 14, 2011, 23:11 UTC
Message-ID
<7vlj0hb8lq.fsf@alter.siamese.dyndns.org>
In-Reply-To
<324BE2A8-5987-4324-AE27-D5CC01341710@appnexus.com>
Joseph Huttner <jhuttner@appnexus.com> writes:
Show 16 quoted lines
> 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.

Previous: Randal L. SchwartzNext: Drew Northup
Message 3 of 4 in “Git workflow for beta/production”
  1. Joseph HuttnerMar 14, 2011
  2. Randal L. SchwartzMar 14, 2011
  3. Junio C HamanoMar 14, 2011
  4. Drew NorthupMar 15, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.