The Continuous Deliverist

I’m sitting on the tarmac at JFK, thinking about the next time I’ll be in town. The sponsors of Jenkins User Confence NYC have invited me to speak on Continuous Integration in the Cloud. This talk will be similar to what we shared in Armenia, but with a crowd of hard-core Jenkins hackers, I think we’ll enjoy diving into the weeds a little more.

 

One of the first things we did after forming a tiger team to tackle the CI problem, was evaluate the vendors in the space both commercial and open-source. We had been using TeamCity from Jetbrains because of its deep integration with IntelliJ (we are a java shop). TeamCity has a lot going for it: a slick UI, great claim/blame functionality, and a built in remote run feature which essentially tests every diff against a shadow branch before merging to mainline. Jenkins was adopted in our QA organization, but was used primarily as a job automation system. It wasn’t connected to our version control, and was running on a single virtual machine.

Comparing these two tools was tough. We could keep what we had been using and begin the process of building out integrations to stand up our vision of a cloud-scale CI pipeline, or we could switch to Jenkins, absorb the crappy UI, and leverage the efforts of the community to give us a head start.

In the end, we went with Jenkins, and I’m glad we did. Yes, we ended up having to write a few plugins ourselves, but the initial hacking required to connect with our chosen cloud vendor, Amazon EC2, both it’s single instance APIs and cloud formation endpoints, was largely finished by folks in the community. Jenkins still stinks at visualization, but we have created views which have increased adoption in our org, and which we are now sharing with the community.

I’m looking forward to joining the Jenkins guys at their conference in NYC, stay tuned for slides, photos, and other content from the show on May 17th!