This post was sparked by some work I've been doing recently, I've been fortunate enough to have time to really get under the skin of continuous integration around a large UK-based e-commerce website. I'm busily working on some hands-on blog posts applying what I've learned to one of my open-source projects, but first a little bit of history.

Since my first encounter with continuous integration (CI) in April 2009, I've been through a bit of a journey with it, along which it's intruded on and controlled a bigger and bigger chunk of the whole software process. I've gone from CruiseControl giving me a simple version number, to unit tests and Selenium tests under Hudson (followed by Jenkins), with recent forays into NuGet feeds, automated deployments and code metrics under TeamCity and PSake.

This whole thing's taken me almost four years to get to where I am today, but looking back it really should have taken me as many months – seriously, if you're just getting started with CI, don't waste time playing with the basics. This post will explain the benefits of the most basic CI setup, and take you step-by-step through my journey towards the ultimate CI that automates every hum-drum, error-prone step of your software build and deploy process.

More...

Hi all,

At work we're starting to use NuGet in a big way to componentise and manage dependencies between our different libraries. I remember the first time I needed to setup a package finding the process a little less than straightforward, I've just come to create the NHaml NuGet package and this time round things seem a little simpler, so here's how I've just done it, step by step.

To be clear - this is going to be a 101, beginner's level tutorial. First up, we're going to install the NuGet Package Explorer and create a basic .nuspec file from the an existing .csproj file (the .nuspec file is an XML file the tells the NuGet package command all about your package you want to make). Next we'll take a look at the generated .nuspec XML markup, tailor that .nuspec file to suit our needs, then finally generate and publish a .nupkg package file.

More...

Hi all,

Anyone who's following the FhemDotNet twitter account (at the time of writing that will be... me) may have noticed a flurry of tweets the last few days.  I've been experimenting with ways to improve the build feedback and performance I'm getting from Jenkins, using multiple build jobs and the "Copy Build Artifacts" plugin. I've now got the ability to check in a code change, Jenkins will run a build job, and then fire off two test jobs simultaneously (unit tests and integration tests), tweeting passes and fails for each of the three jobs, and giving me quicker and more detailed feedback along the way.

It took a fair few stabs to get it right, so best I share my learnings.

More...

Yesterday (and the day before, and the day before that) I spent some time try to get my Subversion install to send a message to Twitter when I commit some code.  Yes, I know it's a fairly pointless feature, but it started off as a bit of fun, which really I should have cut and run after the first hour of non-progress.  But I'm a stubborn kinda guy, so I ploughed on, and eventually got it to work.  Here's (some) of the story.

If you want to know how I got it to work, skip straight to step 4.

More...

This post is the first in a series of posts talking about the ingredients that have gone into the project so far.  I'm still acutely aware that there's no public code yet, but as a sort of stalling tactic, let me talk about some of the things that have gone into the project so far.  This first part is a look back at the first few days of the project, way back in November last year.

If we use a bread-baking analagy (a crummy analagy, I know), these ingredients are the standard essentials whether you're making .Net web-bread or Java app-bread - things like a bread tin (source control), an oven (continuous integration tools), a rolling pin (build tools), etc.  My next few posts will look at some of the later ingredients in the process, such as the tools I'm using for testing, exception handling and event logging, isolation frameworks , dependency injection, etc.

More...