• XP2012 is in Neo Technology’s hometown of Malmo, Sweden [link]
• The BCS CMSG conference program is also out [link]
• VMWare sent a reminder for VMWare Forum 2012 next week  [link]

News:

• Rackspace are blinging up their cloud product, and adding cloud databases [link]
• Cloudbees are doing a webinaar on ALM for PAAS [link]

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

I’ve been running Puppet in a atypical way for some time now.

• No Puppet Master
• No distribution packaging
• No commit until I know something works
• Only test from the outside

The only thing I feel I need to expand on is the last: testing.  Obviously if you write Ruby code, you should rspec the hell out of it.  But should you test Puppet code?  It’s mostly a declarative language.  If you’re properly declaring the outcomes that you want, then it can be easy.  If too much logic creeps in, you’re doing it wrong or you should write a function or type – and you should rspec the hell out of that.  This approach has served me for years with decalarative build tools*.

I have no desire to go verify that Puppet does what I tell it.  But I do care about the outcome.  Also, I need to know that it runs on the target platform, as I use a MacBook.

So I wrote Skewer.   Skewer’s only job is to:

• Provision cloud machines (or connect to existing ones)
• Bootstrap Puppet (via shell scripts and rubygems)
• Run Puppet
• Optionally run Cucumber features at the end

That scratches my itch.  Skewer probably won’t scratch your itch if you run lots of nodes.  It works on Ubuntu, though adding support for other operating systems wouldn’t be too hard.  You may also like the Puppet Cloud Provisioner.

Skewer evolved from a Rakefile that I used to test my puppet code.  I set out to rewrite it over the Christmas period, and got the last feature passing on Friday.  Like my other open source project, I learned a lot while doing it.    Skewer has some wrinkles, but I use it in my day job, and I’ve managed to keep that so far.

https://github.com/builddoctor/skewer

http://rubygems.org/gems/skewer

* Okay, I actually do a little bit more.  I use Rake to run puppet parser validate on every .pp file in my project, and I use puppet-lint to catch howlers.

Skewer – a tool for provisioning cloud nodes with Puppet is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

• Sonatype are announcing a build-time inspection feature for your artifacts, presumably so you can fail the build on crap dependencies [link]
• Cloudbees are making the Jenkins UI more usable – I’ve road tested it, and it helps a boatload [link]
• TeamCity 7.0.2 is out [link]

• I’m a CruiseControl committer.
• Chris Matts and Olaf Mattson are seeking funding for a Business Graphic Novel. This is Maus, but for Real Options. [link]

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

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

So I jumped ship. To a startup, that wanted to change the world of media, but changed investor money into the exact opposite of money. Freelance seemed like the only safe option.

Running The Build Doctor Limited has been a great ride. But I miss camaraderie. Which I’ve found, with the Neo Technology crew. On Monday, I join Neo as a full-time employee. We’re going to deliver a fabulous graph database, and you’re going to love it.

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

https://github.com/builddoctor/xfd-core

Thanks to the efforts of Kush, you now have:

• a plain vanilla XFD, that you can style to fit your organisation
• all the code to talk to different CI servers
• with rspec support, and a Travis build:

http://travis-ci.org/#!/builddoctor/xfd-core

The next release of XFD will use this project. Dogfood will be eaten.

Happy hacking!

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

What’s new with Bamboo?

The Bamboo team has been hard at work for the last few months rethinking and rebuilding the way developers use and interact with CI when a team uses branches. Many thought leaders have come to the conclusion that feature branching and continuous integration are ultimately incompatible because all branches cannot be tested easily. Bamboo 4 is all about proving this wrong.

For example, when a developer commits to a new branch, the developer must go to the CI server to clone and update the build configuration to take into account the new branch. This is needed to ensure commits to the branch are tested correctly by running the full test suite. This is a big problem because a developer has to remember to manually create a new build for their branch each time, as otherwise code does not get tested for large spans of time. And let’s face it, we are a lazy bunch when it comes to processes.

Keeping the configuration between the main build and the branches synchronised is a lot of work and we end up with a maintenance headache.

Bamboo 4.0 solves all these problems by sharing build configuration between the main build and the branches. Working with branches and CI has never been faster and easier.

If you are using Git or Mercurial, Bamboo can automate even more for you. Bamboo will automatically setup a new build when a developer pushes a new branch to the repository and will also automatically clean up any branch build configurations that have been unused. This means that your CI server doesn’t remain cluttered with dead branches (of course all of this is configurable and we never delete branches in your repository).

The other problem is that when we create the branch and manually setup a build for it, we are not sure whether the changes on the branch will integrate with the master branch until it’s time to merge the branch into master (or another branch for that matter). If you don’t run the full test suite before pushing your changes back to master, then you could be potentially slowing the whole team down by introducing bugs and failing tests.

For Git and Mercurial repositories, Bamboo will attempt to merge changes from (or to) the master branch then executes a build against the merged changes. If the build passes, the changes are optionally committed and pushed to either the branch or the master. That’s fantastic for situations where you need to keep your branch updated with the latest changes from master or want to automatically push changes on the bug fix branch back onto master when the build passes.

We think we have really nailed it and we can’t wait for developers to start working with branches and CI together the right way.

We’re in an age where CI servers are all very similar, what makes Bamboo stand out?

Ecosystem

Firstly and foremostly, we truly believe Bamboo is the best CI server out there and it only gets better if your team is using JIRA, Fisheye and Bitbucket. Mention a JIRA issue in a commit message and Bamboo will automatically provide detailed information about that issue on the UI wherever the commit is displayed. If your repository is indexed in Fishseye, then looking at the commit details is only a single click away in Bamboo. As Atlassian builds and acquires more products, Bamboo will add integrations with them (so stay tuned!). We’ve already got a plugin that allows you to broadcast build notifications to the entire team using our cool new communication tool, HipChat.

Bottling best practices

One thing our team and I believe in strongly is that Bamboo should be flexible enough to work your way, not the way that ivory-tower droids think development should strictly work.

Our approach is to marry best practices with flexible features wherever possible to allow you to setup your CI server the way you want it. For example, Continuous Delivery influenced the design of the Stages feature heavily. Stages are the flux capacitor of Continuous Delivery – they not only make it possible, but make configuring it pretty painless. Stages give developers control over their workflow by allowing the steps in the build and deploy pipeline to be split into groups. A Stage can be automatically triggered when the build runs or be launched manually by pushing a button – whatever works better for the team.

The kicker is that Stages let you run a few steps sequentially, then run a few steps in parallel, then go back to sequential execution. For example, you can run compile, package and deploy steps in sequence, then run a several batches of tests in parallel, then switch back to running one step at a time as you deploy the package to a staging environment (only if, and only when , all your batches of tests finish successfully!). You could then have another stage that deploys into a production environment. Going back and forth like that is a huge pain to configrure with other CI servers as the configuration tends to be rather brittle. We have tried to make configuring deployment pipelines like this as easy as possible in Bamboo.

Extensibility and stability

Having a stable API is a must for anyone who wants to rely on plugins. In Bamboo 3.1, we introduced the concept of Tasks which represent user configurable steps of the build process. The Task API been stable for over four major releases, from Bamboo 3.1 all the way to Bamboo 4. Right now we are working with a host of commercial software tool vendors to integrate their tools as Tasks. They simply wouldn’t have had the confidence to try to do this without the stability or the simplicity that the Task API has to offer. That fact has really shined through with the amazing growth we have seen in the number of plugins available for Bamboo since Tasks were introduced.

Design

We believe that not only should tools make it easier todo your job but they should look, feel and behave great if you are going to use them day in and day out. No CI server is as easy to understand and work with as Bamboo. Every day, we think about how to make Bamboo’s UI as clear and simple as possible so teams can find the information they need faster, and get back to the business of making awesome software.

24/7 Support

Bamboo support is 24/7 which is a rarity in our space. Our support team kick ass – plain n’ simple. They go out of their way to help resolve issues when things go wrong and feed info directly back to the Bamboo dev team. If you contact support at Atlassian, you are going to get a fast response.

Analysis: Atlassian are raising the bar; taking things of clear value (auto merging of loony tunes features branches, etc.) and making the accessible. Not a bad strategy, and shows you that James has done his share of developer time.

Sponsor Danger: Atlassian sponsor this blog, and I am disclosing this interest.

Bamboo 4.0 – interview with James Dumay is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Q: Where did you start out?
A: Borland was a great place to start out (first real job out of college), and I learned a lot. However, the CEO was insane and there was a strong personality cult around him that made it hard to reign in his bad ideas. For example, Borland was really really well regarded with regards to its compilers and if had stuck to that we might have been okay. But Phillipe Kahn (CEO) had this idea he could beat Microsoft across all technical verticals and so started acquiring other technologies like databases and stuff. We had so many products that we were competing against ourselves in some instances.

Microsoft finally noticed and squished us like a bug. The team at Borland I was on (Languages) got totally pillaged. Microsoft lured away almost all the top talent, including our VP. They probably spent 10 million dollars on signing bonuses. It was a mess.

Anyway, I got hired at Netscape after about 3 years of Borland. Somebody I had previously known at Borland pinged me and told me of an opportunity at this new startup Netscape. I was the first build/release engineer hired, and I only had 3 years of experience at a very sedate well-established company under my belt. Best analogy I can think of was that it was sort of like jumping out of an 747 without a parachute. There wasn’t a consistent build platform, even within the same general operating systems group.

For example, there were two distinct make systems in play in the unix world. The revision control system (CVS) only worked on unix at the time, so for Windows and Mac platforms we had to run this crazy software to export the local hard drives as mounts readable on the unix network, and then people had to run xterm sessions to do any SCM transactions. It sucked.

Q: What was the problem that caused you to need Continuous Integration?

A: It was the fact that we had 2 version of MacOS (68k and PPC), two versions of Windows (16 and 32 bit) and (initially) 8 versions of Unix. At any given time our ability to successfully generate a set of builds was close to nil. Things would work great on one platform, but not on 6 others.

The most famous of these was when Brenden Eich took out the world by checking in the use of a NaN in the early javascript code (not called that then of course, but that’s what LiveScript turned into). Turns out NaN was totally unsupported by 60% of our platforms. Sadness. On the other hand, to show his contriteness he bought me and my team a whole lot of expensive booze, so that worked out okay in the end.

Tinderbox really evolved out of desperate self-defence, because it was almost impossible for us to do our jobs — mainly, get builds out the door in a timely fashion, and let developers know as soon as possible that they broke something somewhere and to please go figure out how to get it fixed.

About Tara:

Tara Hernandez is a specialist in software engineering infrastructure having developed procedures and tools at assorted Silicon Valley companies. Her most notable stint was at Netscape Communications Corporation where she initially helped develop new tools such as Tinderbox, Bugzilla, and Bonsai, and later helped adapt those tools to a public environment after the creation of mozilla.org and the release of the Netscape web browser as open source. Now at Pixar Animation Studios, Tara and her team are reinventing development infrastructure to handle the challenges of writing software in a film production environment.

The Godmother of Continuous Integation: An interview with Tara Hernandez is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

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

• Pulse 2.5alpha is available to palpitate, with lots of incremental features [link]
• TeamCity 7 is out, with improved Build Chaining (pipelines) and lots more [link]
• I missed the Nexus 2 webinar, but I plan to watch the catch-up [link]
• UrbanCode [warning, sponsor danger] are doing a webinar on Next Generation Continuous Delivery [link]
• ThoughtWorks are attempting to link Continuous Delivery and MVP in a webinar [link]
• CloudStack are hosting a virtual ‘Build a Cloud’ day, with speakers from CloudStack, Citrix, Xen.org, Red Hat, Gluster, PuppetLabs, Opscode, Zenoss and enStratus. [link]
• ‘The little book of CoffeeScript’ is on special. I’m buying me one of those. [link]

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