As automated builds become more popular, one of the main principles is to avoid breaking that build. The basic idea is that your team has an official server that regularly gets all the source code from source control and recompiles the entire project. If you check in source code that causes the build to not compile on this server, then you broke the build. We assume that the relevant environment (programs, external DLLs, version of .Net) on your machine is the same as the build server, as these change infrequently. Of course this dedicated server can do more than just compile the code, such as run automated unit tests. Check out NAnt for links on this.
Nobody wants to be the person who breaks the build. Here are some tips that I've learned (the hard way). The main concept is that before you check in changes, you want to compile the code on your machine, and if your code matches the code on the server, then it should compile on the server too. Build problems often result with your dev machine being out of sync with the build server.
- Work in small increments because there is less that can go wrong. Someone once said "Integration is a pay me now or pay me later" (I think it was Fowler). It's easier to integrate 5 small things than 1 big thing. Therefore if you're given an extensive 2-week task, see if you can break it into daily increments, where each check-in is still functional. XP talks about this more.
- For new classes that are in progress, you can check in just the class to "shelf it". As long as you don't check in the project, the build server won't try to compile it. For example, say you're spending 1 week on a new WebForm. You could check in your progress at the end of each day without fear of breaking the build because that file isn't included in the build.
- Use a source control that allows multiple people to check out the same file. This is why I no longer want to use Microsoft's VSS for enterprise apps, which has such a file-lock model. CVS or Subverion do not. Certain common files, like the *.proj file are constantly being updated as new pages are added to the project, and it's just a constant thorn for a 10 person team to let only 1 person check this out at once.
- NOTE: If you do need to use a file-lock source control system, them minimize the time you have such global files checked out. For example, you may add all the new files you need, and then check back in the *.proj file before implementing those classes. This will (1) Not break the build because you haven't implemented anything, (2) Give you the files you need to finish your task, and (3) not have that global file checked out.
- Before checking into the repository, update your local source to the latest from source control. This helps prevent some other dependency that changed from breaking the build. Even if your code compiled before, this helps ensure that someone else didn't change something such that the official build gets broken when you check in.
- For complex changes, check in everything at once. Partial check-ins are a common cause of broken builds. For example, say you add a class to the project, but only check in the project file. The code on the build server now has the updated project file, but not the class it was expecting, and the build will break.
Another technique, one I've only heard of but never implemented myself, is to have a queue. I think some groups at Microsoft do this. The idea is that instead of checking your code directly into the official build, it is checked into a queue instead. Then a process on the build server takes each fileset, one at a time, and integrates it into a temp build. If and only if that passes, then it adds the fileset to the official build and removes it from the queue.
[Update]: If the build is broken, try to avoid checking in source code. This will (1) make it easier to fix the build because it's not changing, (2) limit your association with the broken build.
No comments:
Post a Comment