Workflow Recommendation - Probably your 1000th

Workflow Recommendation - Probably your 1000th

[bradford]

You guys probably receive a ton of workflow related questions.  I'm
trying to convert from svn to git.  In order to complete, I would like
to be able to provide a workflow to our team.  We typically go from
dev -> qa -> production (Java and Rails projects).  The problem is
that sometimes QA can get backed up and we'll need to release
something to production while QA is doing their thing.  What is a good
workflow?  I would like to not use git-flow, because it's another
tool.  I've read suggestions to use environment branches (master,
staging, production).  I've also read not to do this and just use
master, tagging your production releases.  How well would our setup,
where things can get backed up, work with the latter?  Are there any
alternative suggestions?

Thanks,
Bradford

Re: Workflow Recommendation - Probably your 1000th

[Stephen Bash]

----- Original Message -----
> From: "bradford" <fingermark@gmail.com>
> To: git@vger.kernel.org
> Sent: Thursday, December 1, 2011 1:26:10 PM
> Subject: Workflow Recommendation - Probably your 1000th
> 
> You guys probably receive a ton of workflow related questions.  I'm
> trying to convert from svn to git.  In order to complete, I would
> like to be able to provide a workflow to our team.  We typically go 
> from dev -> qa -> production (Java and Rails projects).  The problem 
> is that sometimes QA can get backed up and we'll need to release
> something to production while QA is doing their thing.  What is a
> good workflow?  I would like to not use git-flow, because it's another
> tool.  

Hey wow...  I read that Driessen's workflow post [1] a long time ago, but hadn't run into the git-flow tools until a few days ago.  Guess I was just oblivious...  Anyway, if it's any consolation, my company runs a model very much inspired by Driessen's post without using git-flow itself.

[1] http://nvie.com/posts/a-successful-git-branching-model/

> I've read suggestions to use environment branches (master,
> staging, production).  I've also read not to do this and just use
> master, tagging your production releases.  How well would our setup,
> where things can get backed up, work with the latter?  Are there any
> alternative suggestions?

In our workflow we flip Driessen's model on its head.  master is the newest code, while we branch off maintenance branches just before each release.  We tag each release so it's easy to identify which versions in the field contain a given bug or fix (multiple minor versions come off a single maintenance branch).  Our QA guys follow the maintenance branches (they're relatively stable).  We recently had to do a hot-fix release which I think would be similar to your "release to production".  Basically we found the last commit on the maintenance branch that was well tested, created a new branch from there, did the hot fix, QA did some real fast testing (sounds like you'd skip this step), and we shipped that.  As always that hot-fix release gets tagged, so in the future we can still reference t
 hat particular build (and in this case the branch merged back into the maintenance branch -- we've had other situations where the branch was simply deleted after tagging).

In the grand scheme of things our model isn't that different than Driessen's; we just name the branches differently.  Commits go on the oldest branch that's safe for them, and then everything merges to the newer branches.  Tags provide easy reference for where on a given branch a release came from.

Hope that helps.

Stephen

Re: Workflow Recommendation - Probably your 1000th

[bradford]

Thanks, Stephen.   I guess I'm looking for more input on the
advantages and disadvantages of using a QA and production branch vs
just doing everything out of master.

Trying to go through the following:
http://news.ycombinator.com/item?id=1617425
scottchacon.com/2011/08/31/github-flow.html

We have some weeks where we release very frequently and some weeks
where we release only once a week and have to do production fixes in
the meantime.  Sure other people have similar experiences.

On Thu, Dec 1, 2011 at 1:55 PM, Stephen Bash <bash@genarts.com> wrote:
> ----- Original Message -----
>> From: "bradford" <fingermark@gmail.com>
>> To: git@vger.kernel.org
>> Sent: Thursday, December 1, 2011 1:26:10 PM
>> Subject: Workflow Recommendation - Probably your 1000th
>>
>> You guys probably receive a ton of workflow related questions.  I'm
>> trying to convert from svn to git.  In order to complete, I would
>> like to be able to provide a workflow to our team.  We typically go
>> from dev -> qa -> production (Java and Rails projects).  The problem
>> is that sometimes QA can get backed up and we'll need to release
>> something to production while QA is doing their thing.  What is a
>> good workflow?  I would like to not use git-flow, because it's another
>> tool.
>
> Hey wow...  I read that Driessen's workflow post [1] a long time ago, but hadn't run into the git-flow tools until a few days ago.  Guess I was just oblivious...  Anyway, if it's any consolation, my company runs a model very much inspired by Driessen's post without using git-flow itself.
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/
>
>> I've read suggestions to use environment branches (master,
>> staging, production).  I've also read not to do this and just use
>> master, tagging your production releases.  How well would our setup,
>> where things can get backed up, work with the latter?  Are there any
>> alternative suggestions?
>
> In our workflow we flip Driessen's model on its head.  master is the newest code, while we branch off maintenance branches just before each release.  We tag each release so it's easy to identify which versions in the field contain a given bug or fix (multiple minor versions come off a single maintenance branch).  Our QA guys follow the maintenance branches (they're relatively stable).  We recently had to do a hot-fix release which I think would be similar to your "release to production".  Basically we found the last commit on the maintenance branch that was well tested, created a new branch from there, did the hot fix, QA did some real fast testing (sounds like you'd skip this step), and we shipped that.  As always that hot-fix release gets tagged, so in the future we can still reference that particular build (and in this case the branch merged back into the maintenance branch -- we've had other situations where the branch was simply deleted after tagging).
>
> In the grand scheme of things our model isn't that different than Driessen's; we just name the branches differently.  Commits go on the oldest branch that's safe for them, and then everything merges to the newer branches.  Tags provide easy reference for where on a given branch a release came from.
>
> Hope that helps.
>
> Stephen

Re: Workflow Recommendation - Probably your 1000th

[Stephen Bash]

----- Original Message -----
> From: "bradford" <fingermark@gmail.com>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: git@vger.kernel.org
> Sent: Thursday, December 1, 2011 3:46:52 PM
> Subject: Re: Workflow Recommendation - Probably your 1000th
> 
> Thanks, Stephen.   I guess I'm looking for more input on the
> advantages and disadvantages of using a QA and production branch vs
> just doing everything out of master.
> 
> Trying to go through the following:
> http://news.ycombinator.com/item?id=1617425
> scottchacon.com/2011/08/31/github-flow.html
> 
> We have some weeks where we release very frequently and some weeks
> where we release only once a week and have to do production fixes in
> the meantime.  Sure other people have similar experiences.

Before continuing I guess two key assumptions factor into our workflow:
 1) we still work in a traditional major/minor release cycle with potentially weeks or even months between releases
 2) our customers can be running almost any historical version of our software

>From that perspective having a maintenance branch for each major revision of our software gives us a holding area where devs can fix bugs at any time without necessarily going through the entire tag/release/merge process (you can envision a "hot fix branch" that is long-lived).  For example, we often have documentation fixes that will sit on the maintenance branch until a software fix needs to go out.  But other non-critical fixes also end up waiting on something that really requires a maintenance release (or enough fixes pile up and necessitate a release themselves).

HTH,
Stephen