[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Using branches for safely updating a website

From: Matthew Nuzum
Subject: RE: Using branches for safely updating a website
Date: Mon, 1 Jul 2002 12:22:48 -0400

Dan Barrett said:
> ... we've got a fairly
> complex
>   app at work (tons of J2EE components), and I'm nominally in charge
>   CVS/builds/etc. on top of coding.  We have three boxes: dev (for
> developers
>   only); test (for testers / the boss / a select number of pilot
> and
>   of course, live.  All code on CVS is the most current.  Dev gets
> every night
>   automatically (`tag -R 'build_DD-MONTH-YYYY-HHMM'` and then built by
> telling
>   Ant to assemble that tag name).  Test and live get trickier.  Once
> boss
>   identifies features that need to be added or bugs to be fixed, we'll
>   actually build a release by hand-tagging files -- that release is
> out on
>   test and messed with.  If it's cool, it gets promoted to live.  Once
> hit a major release (*.0), the stable code becomes its own branch.
>   Trunk remains sexy new stuff, branch is the end-of-life stuff that's
> use
>   by actual users.  Any bugfixes to the branch get merged into the
>   This works fine because your stable code sits in a nice safe
> and
>   the developers are free to hammer on the trunk.  Moral of the story:
> whilst your dev box can easily be built automatically,
>   once your app gets complicated enough you will have to have a real
>   human sit there and assemble a build / release.  As for the common
> commands, for which of them would you like examples?

Dan, thanks for your insight.

It sounds like your situation very closely parallels my own.  I have a
slight difference in that I'm using PHP which doesn't need to be
compiled.  But it seems all that you said applies.

Let me outline briefly the way I perceive you're set up and then ask a
couple of questions:
1. Main trunk is for testing.  Everyone works off the main trunk.  This
is nice because it's very easy to work off the trunk.
2. Items are tagged for testing at some interval.
3. Once tested, items are tagged for release (or using my terminology,
as "clean" or stable)

In another e-mail, Kaz Kylheku stated:
> ... You don't want to be trying to move changes
> from the trunk to a branch.
> The big difference from your approach is that the servers are not just
> updated willy-nilly; it's a decision that is made. ``Okay, we have
> some useful work on the trunk and nothing seems broken. So let's tag
> it, and update the testing server exactly to that build.''

This seems to jive with the above statements by Dan, and it makes sense
to me as well.

So my questions now center onto tagging and how it works on large (for
me) projects such as this.

Some parts of the site are stable and will not need to be changed for a
considerable amount of time.  Other areas of the site get frequent

Is it possible (or desirable) to do something similar to the following:
1. Test everything and bring it into a good stable release.
2. Tag the whole application.
3. Work on a few files, test and deem as stable and ready for release
4. Give these new files the same tag as the previous stable release

Item #4 being the key.  My fear is that we will never have the whole
application in a tested and clean state again after #1 is accomplished.
Maybe this is a design mentality that I need to change.

Additionally, doing QC on the entire application is very time consuming.
It takes days for a small team to test everything.

Jouni Heikniemi said:
> Ps. If you think manually updating the site is problematic and don't
> to bother with versioning, you can add a cron job which does something
> like "cvs update -r READY-FOR-PUBLISHING" on a regular basis. Then
> you can just "cvs tag -FR READY-FOR-PUBLISHING file1 file2 file3" to
> updated and tested files live.

This implies that I can standardize on a tag name and tag everything as
CLEAN or similar and just keep that updated onto the live webserver.

> Pps. Website versioning is greatly underestimated. It slows down the
> that users see the enhancements you make, but it makes managing the
> much easier AND increases quality. Consider this :-)

Yes, QC is becoming more and more of an issue.  When you're pre 1.0
feature completeness is most important; now that we're past that hurdle,
quality control is taking more and more of my time.

Thank you for your input, Dan Barrett, Kaz Kylheku and Jouni Heikniemi
for your quick and useful responses.

Matthew Nuzum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]