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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html