Development

Literate builds, WTF?

(This is a guest post by Stephen Connolly)

Every developer, at some stage, will be handed a project to maintain that somebody else was responsible for. If you are lucky, the developer will not have left the organization yet and you get a brief Knowledge Transfer as the developer packs up their desk before heading on to their new job. If you are unlucky, you don't even get given the details of where the source code is hiding.

Now begins the detective work, as you try to figure out how to build and release the project, set up Jenkins jobs to build the project and run the tests…

It doesn't have to be this way, you know!

What if I told you there was a file sitting at the top level that told you exactly how to build the project and do the important things? You'd be interested, wouldn't you?

When I tell you it's the README file? “But that's all lies. Nobody keeps that up to date. Argh!!!”

But what if Jenkins reads the README file and uses it for the build definition? Now you not only have a CI system ensuring that the build definition is correct, but you have less work to do setting up the job.

What if, because the build definition is now in Source Control, you can have Jenkins create jobs for each branch with ease?

Loader.io plugin developer interview

This is a guest post by Mike Rowan, VP R&D at SendGrid.


Q: Tell us a bit about what your service and plugin do. Who is it for? What are the highlights of your plugin?

A: Loader.io is a simple-to-use cloud-based load testing service. The service is designed for developers and people who need to ensure applications are performing as they should. It allows developers to perform large-scale load tests on demand, which lets them understand the scalability and performance of their applications. We realize Jenkins is the preferred build service for a lot of our users, and we know providing a way for them to implement, measure and improve application performance during the continuous build cycle is important. So we wrote a Jenkins plugin that allows load testing to be brought into the continuous build and deployment process with ease.


Q: Did you have to convince your boss/lawyers to open-source your plugin? What was the pitch?

Extreme Feedback Lamp, Switch Gear style

This is a guest post by Aske Olsson

Extreme feedback is an incredibly powerful way to drive quality and accelerate your developer fast feedback loop.

Having eXtreme Feedback Devices (XFDs) hooked up to your Jenkins jobs gives everyone on your team instant insight into the current software state. At customer after customer we've seen extreme feedback devices drive significant incremental productivity gains, so about a year ago we started talking about taking the concept mainstream and making it easily available to any development team. So, as a small side-project, we've decided to scratch our own itch and developed an easy-to-deploy, Linux-based, laser-cut, extreme feedback device, specifically designed for Jenkins. It infers a feeling of urgency when the build is broken, and a better sense of a achievement once the problem is fixed. Just connect the XFD to your network, install the "extreme feedback plugin" on your Jenkins server and configure which jobs to feedback extremely.

2 version control plugins in beta testing before a major release

Git plugin and TFS plugin are calling for interested parties to try out their 2.0 beta binaries before they get released.

Git plugin 2.0 contains a major refactoring and UI simplifications, and TFS plugin contains a rewritten polling logic that does not require a workspace.

If you think you'd benefit from these changes, please head to their respective beta testing page and try out the new bits, while we can still change them.

Faster slave classloading


Jenkins comes with the remoting library that it uses to communicate between a master and slaves. This is a pretty awesome library, I think, which served us well.

One of the things this remoting layer does it to transfer the Java byte code on demand from the master to slaves on demand. This approach helps us keep slave deployment simple, as you don't have to keep the master and all the slaves in sync, but it also made the slave start-up slower, because none of the byte code loaded to slaves are kept around. It was all forgotten once the slave gets disconnected.

When slaves are static and stays online for hours, this wasn't a problem at all. But as more and more slaves become elastic (think EC2 or CloudBees DEV@cloud), This delay is becoming more and more noticeable. A similar issue happens when the Maven project type, which uses the same remoting library to talk to the running Maven build.