This morning I came across a blog by Landon Dyer called Dadhacker. He got linked by BoingBoing for a entertaining post that he wrote about working on the Donkey Kong cartridge for Atari. I started reading his other posts and it turns out that I agree with nearly all of his opinions. Except for build boxes. He wrote:
The best thing you can do for your productivity when you’re tempted to set up that spare machine to do extra work for you is to ditch the thing.
If you are the person only using that build machine, I can see that point. Almost. I would argue that it's worth the time to have a 2nd machine in case the first one goes to the land whre DOS is eternally blessed. For a team of programmers, having a dedicated build box is a must have feature. No more guessing which program set which option to build which executable, they always get built the same way. Plus it offloads the build process processing from your development environment and that is always a good thing.
The other advantage to having a dedicated build box is that you have have it do everything. We use FinalBuilder and it's the kitchen sink of automated build tools. We build about a half dozen or so shrink wrap ready applications on our build box and they all pretty much follow the same pattern:
- Get the latest code from source control
- Read an .ini to get the version number and other test resources, the build tool will bake the version number into the compiler and install builder.
- Compile the application
- Collect all of the bits and put them in a folder for the install builder
- Authenticode anything remotely executable that we compiled
- Create the installer from all bits that were compiled in the last step and add the necessary required bits (CaptiveX controls, Assemblies, help files, etc).
- Copy the installer to a deployment folder for QA to test
- Send an email to QA and other interested parties that a new build was available and include a change list in the email.
There are other minor tasks that get performed, but that's the gist of it. And it works for for Delphi Win32 and .NET assemblies, with error handling. The time our department saves that level of build automation clearly outweighs the the maintenance time on the build box.
Continuous integration pwns.
ReplyDeleteI don't think anyone familiar with the concept would debate that.
I introduced CruiseControl.NET over at Davis Vision last year. We've had some issues -- which seem to be SCM-driven, SourceGear's Vault doesn't always seem to play nice -- and I've turned duties over to our new test & release guy, letting him sort out the headache.
Those issues aside, Continuous Integration is nothing but a time-saver and a pain-avoider, once you get people into the "check everything in every afternoon if possible" rhythm. This is especially true when you're building, running automated unit tests, running automated acceptance tests. CI is pure gold.
As far as having a second machine around in case your first one dies ... that I WOULD debate with you. How long does it take to burn a standard dev image onto HDD? Spare me the space on and under my desk.
The space isn't issue for me, I have three machines at my desk. There are times when I'm debugging socket code where it's easier to have two separate physical machines. Plus you have to consider the downtime when the machine goes bust. YMMV rules this one.
ReplyDeleteAfter blowing through 3 drives last year, I'm now running RAID 5 at work and at home. At least when a drive dies under RAID 5, you can still work (just at a much slower pace - I already shredded one drive in the RAID array).
Which version of Vault are you having the problem with? We're not doing CI, but we do frequent builds through FinalBuilder Server and Vault has never been an issue.
Vault 3.5.2 -- apparently there are some known VaultTask issues with this release. SourceGear support -- after a long, difficult struggle to get ANYTHING out of "Gold" Support -- sent us a new build. One not released on the general website. Yeah, that inspires confidence. Needless to say, we didn't pursue it. We're moving to 4.x very soon -- I think the PO is already in place.
ReplyDelete3.5.2 is cranky within the IDE -- of course, the 2003-oriented client doesn't help there. Unfortunately VaultTasks, and even command line, seem to be cranky, period. Entirely new folders or files don't always pull down, unless you go into the Vault client and do it manually. Our non-technical release guy has no end of fund with this.
There were some quirks with Vault 3.5, you'll want to be on 4. We are on 4.0.5 and we plan on moving to 4.1.
ReplyDeleteWe have never had any command line issues with 3.5, we use it every day with FinalBuilder. Is there any chance that the CC.NET side was part of the problem?
I use 4.x at home, and yeah, definitely less quirky.
ReplyDeleteNo, the issue isn't CC.NET related. Like I said, our release guy has issues too. Maybe it's a NAnt thing.