David Weintraub wrote:
> I would be careful about creating a separate "release" branch because
> you end up taking pressure off of the developers about getting their
> code to work.
That sort of depends on the culture and interaction between developers,
though. If you have rapid changes and multiple developers in the same
project, the trunk is sometimes going to be broken and you are better
off recognizing that than slowing down work or discouraging developers
from committing early so other can start using their new features. But
you have to do some QA before releases, and a release branch is the
place to do it.
> I believe in the "Finger o' Blame". Whenever something goes wrong, the
> Finger o' Blame points to the scapegoat... I mean culprit. Right now, if
> the build breaks, the Finger o' Blame swings around and points to the
> developer who did the checkin. By creating a release branch, you are now
> personally responsible for the code on the release branch. If bad code
> gets put on there, the Finger o' Blame now points to you.
As it should, if you are the person doing QA.
> I've gone the release branch route before. What happens is that it takes
> pressure off the developers to make sure their code works. If a build
> breaks, they simply say they're in the middle of something important,
> but they'll get it fixed as soon as they can. If you talk to their
> manager, the manager will side with the developer. Why are you so
> concerned? The release code is still good.
>
> Sooner or later, either by chance, or decree (last minute fix needs to
> be sent to the customer!), that release build will break, and it will be
> your fault for putting bad code on the release branch. The whole shop is
> now in a tizzy because a release needs to be done, and because of your
> incompetence, the release can't be built.
Someone has to have the authority to say something should or shouldn't
be released... Maybe you don't want to be in that position, but just
shipping the trunk isn't likely to be better.
> Do you have a continuous build system like Hudson or Continuum? Those
> will do a build every time a commit is done. They will also show you who
> did the change, what was changed, and why. Hudson will give you a link
> to the last good build artifact for testing, so QA knows where to find
> the build to test.
Yes, Hudson is great and integrates nicely with subversion. If you have
automated unit and acceptance tests, let it do the grunge work for you.
> Hudson also reports the Subversion revision number used for the build.
> Many shops use that instead of a build tag which makes updating easier
> because you can simply use the revision number instead of switching to a
> tag. By the way, checking out tags can be a problem because it is
> extremely easy for a developer to commit changes on a tag without anyone
> realizing it! I have a pre-commit hook I use that allows users to create
> a tag, but be unable to actually modify that tag.
Hudson can even create 'good' tags for you when a build and tests
complete successfully - but you can also just work with the revision
numbers.
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389872
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-01 20:35:01 CEST