Re: Using tags to manage releases?

On May 31, 2011, at 12:59, Charlie Davis wrote:

> First off, we are using Subversion for web site assets.
>
> Since its a website, its a very "organic" property. The method of
> developing towards an end goal and then releasing that, doesn't really
> work for us. Meaning, everyone working in Trunk, getting Trunk to a
> state we are happy, then tagging Trunk to a new branch and using that
> branch for release.
>
> What I'm doing is creating a post-commit script that, based upon flags
> in the commit message, does different actions.
>
> The idea being that someone could do say...
>
> svn commit -m "New awesome function. REL:15" scripts/support.js
>
> My little python script grabs the commit message, parses it out, and
> the idea is that Using the REL: "tag", it does:
>
> svn copy URL:/path/to/repo/trunk/scripts/support.js
> URL:/path/to/repo/releases/15/scripts/support.js
>
> This way we deploy individual files to our QA, stage and production
> environments. Our QA department could just keep their testing copy at
> the /releases/15 branch, our testing environment/production could be
> different releases and our developers can continue ahead working on
> different areas of the site (Maybe developer A will need 2 months to
> do something, Developer B will take three days, etc...).
>
> Remember, we don't want to do big deploys of trunk as a whole, we want
> to be able to deploy parts of the site at a time.
>
> The problem I've come across is that SVN COPY doesn't work if the file
> exists... so... I made my script do a SVN delete, then a SVN COPY, and
> this creates a commit... and we get an infinite loop.
>
> Is there a better way to do this? I feel like I'm missing something.

Yes, please reconsider your strategy. You really *do* want to release trunk (or, if you insist, a release branch) as a whole. You do *not* want to deploy individual files. How could you ever guarantee consistency? You can't. At the last web design company I worked for, before I introduced the team to Subversion, we would manually upload individual files to production by FTP. It was a nightmare of incompatibility. Subversion gives you tools to avoid that by helping you track your code changes and group them together meaningfully into folders, which you can then deploy in their entirety, knowing all the files in them work together.

Consider using trunk as the stable version of your web site. At any time, it should be acceptable to push trunk as a whole to production and it should work. If anybody is going to commit something that's going to break something for awhile, have them make a feature branch, work on things there until they're not broken, then merge it back to trunk.

Whenever you want to release the trunk, tag it. Then push the tag to production. There is a great script to help you with this, called SVN::Notify::Mirror. Look it up. Instead of keying off the log message as you proposed above, it keys off the tag name. (You get to define the pattern in the config file.) So anytime you want to publish your latest version, you simply "svn cp ..../trunk ..../tags/RELEASE-20110601" (or whatever your naming strategy is) and SVN::Notify::Mirror in the post-commit hook in the repository takes care of everything else. Ideally, your developers don't even have the passwords necessary to modify files on the production server, and all changes on the production server happen as a consequence of making a tag in the repository. This ensures all your code changes are tracked and reproducible.
Received on 2011-06-01 13:42:43 CEST