- Jay from TDDium got in touch – there’s another outsourced CI service in town [link]
- Bamboo 3.4 is released, with Windows EC2 support. [link]
- Cloudbees released their Jenkins survey [link]
Happy new year!
(Kushal Pisavidia has been working on enhancements to XFD – it’s only fair that he gets to do the release announcement)
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:
We’re always on the lookout for new servers to add.
Move to CoffeeScript
For those not familiar with it,
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!
Best. DevOpsDays. Ever. Just found my talk video. Much love to Tom and Patrick.
devopsdays Goteborg 2011 – Julian Simpson , Everything I learned about Continuous Integration , I learned from System Administra from devopsdays on Vimeo.
Continuous Integration matters. Configuration Management matters. What happens when you mix the two?
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]
Atlassian kicked off the Bamboo Task Master Challenge today. I am honoured to be on the judging panel.
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:
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]
I was honoured to give a talk at DevOpsDays Gothenburg on Saturday. Much love to Patrick Debois for encouraging me to submit the talk, and huge props to my erstwhile colleague Tom Sulston for agreeing to co-present. The whole thing was a blast.
… this is a repository. I’ve been experimenting with Amazon S3 as a Maven repository. I threw the results up on GitHub [link].
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).