Archive for December, 2009

CruiseControl.NET / Custom Plug-ins

Posted in Coding on December 23rd, 2009 by MrCranky

I must admit, I’m a bit of a CruiseControl.NET fan. It drives most of our automation systems, and provides us a backbone from which we can hang many different systems. I use it both here at the Company, and when I’m doing tools consulting with other teams. That said, it’s not without it’s flaws and limitations; not least of which is the lack of documentation on custom plug-ins.

There are a wide variety of pre-built plug-ins already available, for source control systems like Perforce and Subversion, and build systems like Nant and MSBuild. These usually work pretty well straight out of the box, if you’re building a vanilla continuous integration server. That is, every change made to source control results in a build of some sort. I’m not going to dwell on why that’s a good idea (it is), I’m only going to say that there are times when you need something different. There are inelegant ways around this, but in truth CC.NET has all of the customisability to let you do this properly within the system – by defining your own plug-ins.

Reading the documentation on CC.NET, you get only a single page of documentation on custom plug-ins, and that page is pretty spotty at best. It shows you a “hello world” plug-in, with no clues as to what information you get into the plug-in, when your plug-in’s methods will be called, or how you’re supposed to pass either status information or logging back to CC.NET itself. In short, it’s pretty useless, other than to highlight that the facility is there, and give you enough of a pointer to get you into the code and poking around.

Sure enough, with Auto-complete on, you find that there are lots and lots of information passed to you, and by debugging and breakpointing inside your plug-in, you can get a feel for when your code is called. Making CC.NET load and unload your plug-in is refreshingly easy and fairly robust, and once you figure out how to pass parameters to your plug-in by specifying them in the config file, you can see the possibilities open up. More importantly than the sample building plug-in though is that, through a bit of digging, you find you can also define your own custom source control plug-ins, and with the combination of those two things, you can do pretty much anything you want.

In one particular situation, I’ve been working with a Perforce (p4) source control system, and a rather black-box build system for the game itself. Rather than wanting a build made of every single commit to the p4 repository, I needed it to make only particular builds – those marked as verified by the developer’s internal test team. This is a pretty common situation when you’ve got an automated build system – you have a raw source control system that lies underneath, which operates at the level of atomic commits. But above that is a logical structure, which only people understand – that operates at the level of ‘nightly builds’ and milestones. You have custom logic which you can apply to the system, using some basic rules. So in essence you have a virtual source control system, built on top of the raw version. By writing a custom source control plug-in for CC.NET, you can expose an interface to your automated build server, so that it recognises when something new is available from that virtual source control, and only builds exactly what you want.

CC.NET offers great flexibility, and those people who develop it, know all about that flexibility. But information on what you can do, and how, is rarer than hens teeth. So over the next few weeks, I’m going to write up and publish here some examples of real-world plug-ins that I’ve written. That should hopefully give readers enough context to go off and write their own plug-ins, to suit their own needs.

Disclaimer: all of the points made here refer to CruiseControl.NET 1.4.x, not the later versions of the system. There are some big and eagerly awaited advancements in the newly released 1.5 version, that many people like myself will have to avoid for now, until it’s bedded in.

Lovely cold winters

Posted in Tales from the grind-stone on December 5th, 2009 by MrCranky

Maybe it’s the Scotsman in me, but when the yearly cold-snap hits Edinburgh in late November, it always cheers me up. It’s the time of year when the weather changes from being mushy and wet into being cold and dry. Scarves and hats are no longer a choice to make, they’re simply required. So even the weekly trips up to Dundee become pleasant trips out in the brisk cold. Mind you, in weather like this, the office heating becomes a must. Thankfully, the Microsoft office, in all it’s newness, has great heating.

Unfortunately, the heating in our office is less than stellar at the moment. Our part of the office is fine, but the people we share an office with (Alban Books), have little to no heat at all. They’re all huddled around electric heaters, and still cold for it. Worse still, the thermostat for the entire office is out in the hall, which is poorly insulated from the outside. So the thermostat is convinced that the entire office needs heating up, so our part of the office gets baked, and Alban and the hall remain frigid. And if I’m up at Ruffian, their heating is all screwy as well – with people wandering around with hats and gloves and scarves on all the time. But sadly I keep forgetting  my hobo gloves, which are in the office with Tim! So Waverley Gate is the only place with a reasonable temperature at the moment.

So to brighten up the blog, here’s a picture of the lovely rooftop garden at Waverley Gate. I don’t spend much time out on it, due to the aforementioned cold, but I do like to look out onto it while I’m making coffee or reheating last night’s leftovers for lunch.

photo


Email: info@blackcompanystudios.co.uk
Black Company Studios Limited, 14 Belford Road, Edinburgh, EH4 3BL
Registered in Scotland (SC283017) VAT Reg. No.: 886 4592 64
Last modified: August 14 2014.