Happy new year!

Vendor news, December 2011 is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Happy $EVENT is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

The beginnings of XFD
A little over a year ago on the 4th of May 2010, XFD was born through the work of Chris and Julian. Since that date it’s gone from a minimally viable status indicator, to a tool which numerous companies use with a number of CI servers to keep their build status visible. The current supported list includes:

• Hudson
• Jenkins
• CI Joe
• CruiseControl
• Team City (via a plugin)
• CCNet, cc.rb, Go (via a plugin)

We’re always on the lookout for new servers to add.

Move to CoffeeScript

For those not familiar with it,

CoffeeScript

is a little language that compiles to JavaScript. It takes the “good parts” of JavaScript and exposes it through a cleaner syntax. Making it easier to stay away from the bad.

However CoffeeScript isn’t all about syntax sugar. It’s about being more confident that the code you write is correct the first time, while knowing that tests are less brittle and can be changed in a matter of keystrokes. This has made developing XFD a lot simpler.

HTTP Auth
HTTP Auth is by far one of the most requested features. In this release we’ve added support for both Hudson and Jenkins with more support planned.

Better feedback
In making XFD we sought to make a highly visible build status indicator. Related to the concept of visibility is feedback. This is best illustrated by an analogy to what everyday life would be like without it. Imagine trying to play a guitar, slice bread using a knife, or write using a pen if none of the actions produced any effect for several seconds.

XFD seeks to make this feedback step clearer for build jobs, but didn’t make it obvious what the application was doing at every step. Now, it’s incredibly easy to follow along and get clear information about what XFD is doing as you use it.

Increased accessibility
The emphasis on Red/Green for build status meant that colourblind users may have difficulty viewing the status of their builds. To counter this we’ve added universal symbols in addition to the colours to make this clearer for everyone. The different symbols are used to indicate different levels of importance or urgency with no need to vary their colours.

We hope you enjoy this new release, and let us know what you think!

XFD 0.2.16 Released is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

DevOpsDays Gothenburg Video is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Let’s find out. Chris Read and I are speaking at the BCS Configuration Management group meeting on November 1. We’ll be doing our talk from Agile 2011, which I hope will spill over into a massive discussion over nibbles and wine.

The venue will be the BCS offices in Southampton Street, London. You need to register for security and catering purposes. Chris and I will be talking from 18:30. We’ll be preceded by the CMSG AGM, which non-members are welcome to attend (though you can’t vote unless you’re a member)

[link]

LondonCI Meeting, 1st November is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

What’s it all about? A Continuous Integration server becomes the heart of your development infrastructure. CI servers need to know how to talk to the rest of your systems.

So Atlassian are encouraging you to add to the Bamboo ecosystem by offering the winner of the competition:

• A ticket to next year’s Atlassian Summit
• $500 of nerd toys
• A USB Bamboo keyboard and mouse
• A USB rocket launcher, that integrates with Bamboo

The first 10 entries get an Atlassian T-shirt and the Bamboo Keyboard and Mouse.

I think it’s a clever move. Plugins made Hudson/Jenkins more attractive to it’s users, and gave everyone the incentive to encourage more plugin authors (see Crossing the Chasm for more on this)

Here’s an idea to kick things off: I’d like to see someone use face-detection and face-recognition libraries to detect the face of the person who broke the build.

An targeting system for a Nerf Vulcan wouldn’t go amiss, either.

[link]

Atlassian Bamboo Challenge is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Everything I know about Continuous Integration, I learned from Systems Administration is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Grunge is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

• ViewTier released ParaBuild 4.1 [link]
• Atlassian released Bamboo 3.3 [link]
• Electric Cloud released two new versions of Electric Accelerator 6.0 [link]
• Amazon now include Puppet and Facter in their AMI’s [link]

Vendor news, #DevOpsDays Special is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Why? I’ve been working with some nice people who use binary dependencies. In order to scale their CI system past one node, they need a repository manager, to temporarily store built artifacts on.

They actually have a couple of repositories, but not geographically close to where I’m building out their new CI system (on EC2). It’s important to keep the feedback loop fast; so deploying a repository close to(or indeed on) on the CI server is desirable.

The plan was to deploy Archiva onto an EC2 instance via Puppet. Then I had a better idea: use an S3 bucket as a highly scalable, low latency and (mostly) highly reliable repository.

Turns out that there’s support for S3 in their build tool (Maven). So it turned out to be easy. In the github repo, I publish and artifact using an S3 client, and then retrieve it using plain HTTP.

As long as your EC2-hosted Continuous Integration server is in the same availability zone as the S3 bucket, you’re not going to be liable for a high traffic bill.

They may want to use a different configuration for the real repository, where they serve artifacts to the other consumers. This approach is all about speeding up and scaling out their build.

Update: Oliver Lamy asks: ‘what is wrong with Archiva’?

Nothing. I’d cheerfully use it. It has a permissive license and cheerful absence of public spats with other repo managers.

In this case I wanted some very fast and robust, which led me to S3. The alternative was to deploy Archiva on an EC2 instance: I could have done that, but then I would have had a dependency on a single host.

IMO, this approach is more suitable for the context (caching intermediate build artifacts, on AWS).

Repository? That’s not a repository … is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.