Quote

“A text without a context is just a pretext for whatever you want it to mean”

Build Systems: Version Control and Releasing

This issue has been on my mind a long time. When I first walked into my new job, I was shocked they were using CVS. For making sure no one overwrites others changes, CVS does fine. But for being a real build system? It does not pull its weight. CVS’s merging is infamous, it can’t hold symlinks, and you have to do extra work (tagging) to get what you get for free in other version control systems.

Any build system has got to be flexible. You can’t really anticipate what you might need to do – other than release any arbitrary bit of code at any time. That means flexibility. It doesn’t matter whether you are releasing branches to live environments, or updating trunk on your SaaS service in the live environment – you need to be able to do lots behind the scenes:

1. Branch when you start a new feature
2. Move patches from branch to branch
3. When you merge these branches together they don’t conflict
4. Make a build in 1 step

One of the most understood (and sometimes misunderstood) concept is that what you need to do is push changesets (or patches), not files. You don’t push N files, you push N patches. This is how any modern version control system works (read: not CVS, you need to use tags if you’re using CVS). And you should be pushing SQL to get run as well (RoR uses migrations to accomplish this)! Keep it all in one place, don’t use multiple systems to keep track of things.

Whenever you start working on a new feature, you want to do it on a branch(#1). Keep those changes isolated from everything else. If you need a bugfix or another feature from another branch you replay that patch over to your branch (#2). When you’re done, you merge that back into whatever you’re releasing (trunk or branch). Hopefully it does not conflict (#3). Then you release (#4). You let the code fly up to whatever server it needs to, and the SQL in the repo gets run as well.

Not too many people disagree with that setup. However, this setup also makes a statement towards your dev environment. If you can make a build in one step that means your environment should also be taken care of in that build step. Again most frameworks (like RoR) have methods (YAML, dev, and production modes) to take care of this.

One of the problems I’m coming up against is the inability to run two enviornments side-by-side. The primary reason for this is because I cannot build in one step. I can’t count how many steps it takes to make a build, I don’t even know some of them. This is a problem if you’ve done #1, branch when you make a new feature. Suppose your “new feature” is to make something more efficient. Well a good way to know you didn’t break anything (in addition to unit tests) is to put the old and new environments side by side to see if you get the same output. Currently, I can’t do that. Which makes branching less useful (not to mention the fact it is CVS).

This is the best build system I’ve come up with and actually used in a real environment before. Does anyone else have other examples that have worked for them? I’d like to know.