On 11/13/06, Gundersen, Richard <Richard.Gundersen@london-scottish.com>
wrote:
>
> The idea is that you commit the merged changes once they have been
> > released. You can treat the commit as a step in the release process. If you
> > only merged & released feature X, and you committing that merge, the trunk
> > certainly does reflect production. You could do X and Y at the same time if
> > you like, with the same result. The difference is, you have a CHOICE.
> >
> Ok, I've found the thing I was missing here. You sound like you don't
actually commit until you release to production. Here's how we work:
1. cut code, committing as frequently as possible without breaking the
build, tests, or general functionality (on trunk)
2. create a tag
3. release tag to test for QA
4. if required branch off the tag to fix any bugs, retag (branch) and
re-release to test. repeat as required
5. release QA'd tag to production
You sound like you're doing:
1. cut code on branch
2. once code is complete, checkout trunk and merge branch into working
copy. deploy working copy (not yet committed) to test (???)
3. once tested (how do you handle bugs?) commit to trunk and deploy to prod
I don't like the idea of the commit being part of the release process. That
could just be me, or I could have misunderstood something. To me, I want to
_know_ that we're releasing the _exact_ same thing to prod that was released
to test. Note also that frequently different people do the test and prod
releases. We have a log of what has been released and when something needs
to be released to prod the person doing the release logs into the build box,
exports the tag, builds and deploys. Some people take this even further by
committing their build artifacts and deploying those.
cheers
dim
Received on Mon Nov 13 21:56:07 2006