On Tue, Jun 22, 2010 at 3:47 PM, iguy <ira.l.greenst...@gmail.com> wrote:
> > Rob, > > I realize that this is an old thread, but just in case you remember it... > > In your scheme, where do bug fixes found during testing take place? > > Ira Depends. For example, take this scenario: QA finds a bug in QA build #10, you have this chain (through the 'copied from' paths/revisions you get with svn copy): ^/builds/qa/10 <-- tag created by CI server upon successful build/deployment to QA ^/environments/q...@99 <-- tag created by the build manager to trigger the build/deployment to QA ^/builds/dev/999 <-- tag created by CI server ^/tr...@12345 So now you have a bunch of option as to where to fix the problem, based on whatever your preference/process is, or sometimes the circumstances force you down one path or another, and this approach gives you the tools to do so elegantly, for example: a) fix in trunk (where the other changes going into the build are) b) create a branch from ^/tr...@12345 (to exclude anything on ^/trunk since r12345), fix on branch. This is identical to a release branch approach. You reuse the same branch for any subsequent fixes/changes related to getting that build passed, without affecting the overall scope. c) create a branch from wherever the problem was first reported, in this example ^/builds/qa/10, so I don't have to think/trace where anything originated. QA says "build 10 is broken", DEV says "we need a branch to fix the thing that broke QA build 10", and I say "I'll give you a branch based on QA build 10". This is makes it easier to automate e.g. for (web-based) self-service. Potential downside is that you may end up having a bunch of different branches containing partial fixes for something that took multiple builds to finally resolve. But in a QA-driven process, sometimes having that kind of traceability outweighs keeping related changes in one place. Probably not something I would recommend as a matter of routine. Hope that helps / gives you an idea Cheers, Rob
