On Tue, Jun 22, 2010 at 3:47 PM, iguy <ira.l.greenstein_at_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/qa_at_99 <-- tag created by the build manager to trigger the
build/deployment to QA
^/builds/dev/999 <-- tag created by CI server
^/trunk_at_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 ^/trunk_at_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
Received on 2010-06-22 23:34:46 CEST