Software releases 1: svn structure
Tags: python, django, softwarereleasesseries
Software releases: when you want reliable software, you’ve got to have some
infrastructure in place. And you’ve got to work in certain ways: good habits.
Over a course of (estimated: 6) articles, I’ll show you what to do and what to
set up if you start from basically nothing.
First things first: you’ll need to have all your code (and website
configurations, and...) in a version control system. I’m assuming subversion
(“svn”) here.
But don’t put your project’s code directly in an svn directory named after
your project. In that case, you have one location that you use for:
- Current ongoing development.
- Experiments. But you probably don’t commit those and instead keep them
locally in an uncommitted change because you don’t want to pester your
colleages. If you do commit them, you’ve earned the 220V wiring they
installed in your chair.
- Making checkouts on your live servers. You might do an “svn -r1234”
checkout with a revision number in there, but an “svn up” wipes out that
knowledge and updated to the most recent version.
Solution: a trunk/tags/branches structure. There’s a subversion
convention for setting up your repository. It is a bit of extra bookkeeping,
but it is necessary bookkeeping. Inside your project_name directory you
need a tags, branches and trunk directory. Something like:
The purpose of the various directories:
- Trunk: current development. Trunk should be in a workable state all the
time, otherwise you’re blocking colleagues. So normally all tests ought to
run just fine before your commit. Doing a couple of commits within 15
minutes with intermediary commits breaking is normally fine (warn your
colleages), but if you leave the trunk broken for weeks you ought to be
whipped.
- Branches: maintenance branches or experimental branches or long-lasting
changes. If your changes would disrupt trunk too much, create a branch and
do your work there in isolation and merge back when finished. And if a
customer wants a bugfix for an older release, make a branch off that
release, make the fixes and push out a x.x.1 release. And if you just want
to try out a few things: branch also. Name the branch like
“yourname-purpose_of_the_branch” (for instance
“reinout-adding_script_support”) so that it is clear what the branch is for.
- Tags: every release should be tagged. A tag is simply an svn copy. So
svn cp http://yourproject/trunk http://yourproject/tags/0.1. The idea
is that you can get a reliably fixed snapshot-in-time. It beats the pants
off “svn up -r1234”. And you can make a release of your python project
(zest.releaser-1.2.tar.gz) which will be easy to identify in your svn
(zest.releaser/tags/1.2). You can even generate releases automatically from such a structure.
The exact behavioural rules vary a bit from project to project, especially in
how strict you are in creating new branches compared to working on trunk.
Summary: the basis of proper releases is a good svn structure with
trunk/tags/branches per project.
