Tag Archives: Chef

Automated Builds

Posted on by at 12:13 am

Several hours today were spent advancing my automated build process for Chef. I’ve had CruiseControl.NET building the software for months now but I’ve had a gaping hole in the processes that has been staring at me since I started it.
What is this hole you ask? Version numbering.

Why is versioning so hard in this day and age? Seriously. With .NET there are all these really nice and easy attributes that all you have to do is type in the version string you want your assembly/binaries to have. That works really well, until you want those numbers to be dynamic – then it requires modifying a sourcecode file with a new hard coded string. But what about 1.0.*? you ask, referring to the ability to have the compiler generate parts of it for you. Well, what real good is it to have version numbers that you don’t control? If they get generated by the compiler it just makes everything difficult – like translating between a version label from CruiseControl to the state of source control at the time of the build. Maybe I’m missing something here, but I don’t think I am.

Another versioning issue is setup projects. The setup projects created in Visual Studio have a version number, product code, and upgrade code. Counter to intuition, the upgrade code is the same across versions for a given product and it’s the product code that changes between versions. Sooo, if you bump the version number you also need to create a new Product Code guid. Again, there’s no way (that I know of) to do this via command-line. Microsoft thinks you should open the setup project and bump the version number manually. They even go as far as prompting you to create the new Product Code guid when you do this. Microsoft, the creator of the great tool that is Visual Studio, make it very hard to do the Right Thing and have automated builds. Tisk, tisk.
And finally, the version string has implications on product keys – both generation and verification. For instance, if Suzie buys Chef 1.2, I need to have a way to have that license key work for 1.2.5, 1.4, and 1.9; but not 2.1. And I need to be able to forget about the details rather than think about it every single time I create a release. (Chef Beta 2 is days away, by the way).

My solution to these problems required a little planning, a little coding, and a lot of time waiting for test builds to be created. My process is as follows.

  • I go to the CruiseControl.NET Dashboard website and click Force to initiate the build.
  • The last successful build label is incremented (from 0.9.2.2 to 0.9.2.3, for instance).
  • The latest sourcecode is retrieved from the Perforce depot
  • The code I wrote tonight gets executed on the sourcecode tree, passing in the newly incremented build number
  • A new product code guid is generated
  • Every AssemblyInfo.cs file is edited and all AssemblyVersion attributes are changed to use the new version number
  • The specified .vdproj files (Visual Studio setup projects) are edited to modify the ProductVersion with a trimmed version of the current build version/label. The new ProductCode is also inserted
  • Visual Studio is called upon to perform the compile.
  • CruiseControl puts the generated installation packages out on the network
  • A sourcecontrol Label is created in the Perforce depot, denoting the state of the sourcecode at the time of the build.

And that’s it. With a single click I have installation packages created with no further involvement. The files included in the package all have a version number that I can trace back to a CruiseControl label (to view build logs and in the future unit test results) and then back to a Perforce label with the same name to view the sourcecode files at were a part of the build. I’ll then also be able to compare those file versions with the recorded version numbers of bug fixes in FogBugz – something that will surely save time once Chef is in the wild.

Microsoft, please please please make this better in the future.

Bug Tracking

Posted on by at 7:56 am

The development of Chef has been pretty interesting thus far. I had almost forgotten how much work is involved in getting an application shippable like this. My previous experience was with the release WakeUp! Alarm Clock, but that was as off-the-cuff as you can get: simple version control (umm, none at first then graduated to CVS); no bug tracking; no build process – builds were simply done on my development box; no unit test for regression testing (unit tests, what are those?!); and really no plan whatsoever. But I was in college and had no real experience in software, it was my first.
In these regards, Chef is completely different. I mean completely. My development environment is quite extensive in comparison to the days of old: Perforce for source control; FogBugz for bug tracking, support, forums and a bunch of other things; an automated build system driven by CruiseControl that give me a build and install at the click of a button; full NUnit test cases for the entire Chef API; and multiple VMWare environments for testing. Future posts may include some information on some of these topics, but for now a little information about FogBugz.

Continue reading →

Recipe Sharing and Beta 2

Posted on by at 7:14 am

Chef Beta 2 isn’t quite as far along as I’d like it to be thanks to the Holidays and work.  I’m targeting the middle of January for its release and that’s coming up fast.  A couple dozen bug fixes and features/enhancements since Beta 1 have been done though, with the major ones out of the way.

One of these big features is Recipe Sharing, which I think will be a compelling reason to actually put recipes into the application.  It’ll be very handy to just click the mouse  a few times and be able to give recipes to fellow Chef users. And for sharing with non-Chef users, there’s always copy to clipboard.

So those of you interested should keep an eye out in the next few weeks for the final Beta release, with 1.0 hopefully coming in another month+ after that.

Posted in Uncategorized | Tagged ,

Perforce

Posted on by at 11:41 pm

A while back I discussed needing to look into a new source control solution for Chef.  To recap, CVS had just gotten on my nerves for a few things: file deletion and moving; pretty crappy windows client support (gui); clunky (to me) branch management; and poor infrastructure on my network.  I just don’t feel comfortable using it on Chef going forward.

Some of my requirements for the replacement system:  stable; reliable; simple backup/restores; good Windows GUI tools for management; inexpensive (read Free); intuitive; good documentation; preferrably a Windows server (to simplify my backups).   The two forerunners were a coworker’s recommended, SourceGear Vault, and Perforce.  Vault was built as a Visual Source Safe replacement and is free for a single user.  Perforce, I learned, is a very popular and robust scm server that is free for 2 users or 5 workstations.  After comparing the two for a while I settled on Perforce mostly because it met all of my requirements, and did so in a very elegant and polished fashion.  Documentation has been spot-on and things work as advertised.  I was able to import Chef, get it backed up and configure Visual Studio’s Source Control integration all in a span of a couple hours.  Pretty impressive. Thank you Perforce for the free license.

Build System

Posted on by at 10:17 pm

Last night I put together a simple build system and got some of the application versioning in place for the future.  I’m running CruiseControl.NET for the builds but haven’t set it up for continuous integration since I’m the only one coding.  I’m also not running any build tasks other than a straight compile, although once I get some time that may change to include running my NUnit test cases.

All-in-all, I didn’t spend a lot of time on Chef this weekend, but I got a few very important things done.

In the very near future I need to really examine my source control system. I am using, and have been using, CVS at home for several years.  But I haven’t really used it for more than a simple version controlled file repository – few branches, few labels, etc.   At work I’m very comfortable with our source control system, but I’m just not with CVS.  On my list of possible replacements are SubVersion and SourceGear Vault.  All said, I’m still quite nervous about changing systems.

Registration Keys

Posted on by at 10:07 pm

Over the weekend I finally spent some time to tackle the problem of registration keys.  Particularly, generating them.  The last piece of software I attempted this was WakeUp! Alarm Clock, with a very cheesy, homegrown routine for creating a key tied to the user’s name.  I never ran across any cracks/keygens for WakeUp! but I’m 99.999% sure that that’s because I charged a meager $5 for it.

With Chef, however, I’m planning on a steeper price tag and don’t want to make the mistake of using an easily cracked scheme.  So, I turned my attention to the cryptographic services provided by .NET and now have a simple and, what should be, effective solution using public key cryptography.

I haven’t integrated it into the application yet, but that shouldn’t take too long.  Once the code is in place, I’ll start strong naming the assemblies and even obfuscate them.  The obfuscation will prevent the casual snooper from using a tool such as Reflector to simply copy code and recompile it into a working replica of Chef.  The strong naming will then ensure that someone cannot release a cracked version of my assemblies with the registration limitations removed.  Pretty cool I think.

Today I spent some time reviewing several payment processing options.  Currently, RegNow is the leading candidate.

New Category

Posted on by at 9:55 pm

Just created a new Tech subcategory called Chef to put all of the Chef software related items.