Submitted by kohsuke on Thu, 2013-09-05 07:55
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.
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.
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.
This Wednesday's Jenkins office hours is all about the Git plugin refactoring that's going on.
Git plugin is one of the most popular plugins out there, and it's been around for quite some time. Combine that with the fact that there are so many different ways to use Git, it was inevitable that Git plugin became quite a capable but complex plugin over time. It has more than a dozen options and switches, and it was becoming harder to use and harder to maintain.
As early as 2010, some of us have already been saying that we should refactor this plugin, but none of us have managed. The good news is, I finally started tackling this problem last month while I was in London, and I've made a steadily progress since then and I'm ready for a wider review.
So we'll spend this Wednesday going over the changes.