Vincent Massol had an interesting idea. He is concerned with the problem of having a team "care" about the success of a continuous build. His idea? use a physical artifact on a developers desk to let you know the state of the union. An Ambient Orb can change colors to let you know?
"Imagine you have a continuous build system in place and that it builds automatically your projects every few hours. When the team is large it can be quite challenging to coach all team members in being careful about the build and that before committing code, people need to run the build locally on their machine first. There are also other problems, like the build works locally but not on the continuous build machine.
Anyway, I've found that there are different kinds of projects. Some where the build is taken very seriously and a build-aware mentality quickly spreads and others where people do see the value of the build but have more difficulties taking it very seriously (leading to lots of build failures).
One idea that I've had is to use a physical artifact to represent a build success or a build failure. People like to see and touch things. Doing some research I've found the Ambient Orb which seems close enough to what I have in mind"
Fun huh? How many teams are taking the continuous build seriously?
Read Vincent Massol on Enlightening Build
How about an interactive 3d visualisation of the build based on the jsr-77 management model.
Components could grow grey with age, pearly white when newly build, glow red when faulty, the user could then ask the component directly what is wrong with it and who is responsible.
The idea is that the entire development group would have a shared understanding of the system and of the system's complexity.
I worked on a project several years ago (non-Java) where the responsibility of the daily build (overseeing the process, coordinating fixes to ensure the next build was good) was passed to whoever checked in code the previous day that broke the build :-)
It worked as an incentive to make sure that you only checked in well tested code...
This is what we do too. More specifically each project has a team associated with it (we use Maven and the team is described in the project.xml file). Whenever the build of that project fails an email is sent to the whole team. We're actually refining a bit our model as we'd like even more reactivity. We're now going to have a build leader in each project whose goal is to ensure the build is taken care of as a priority whenever it fails. That person will investigate, asking people to fix things, etc, until the problem has been fixed.
Just to give you some figures, our current project has a development team of 100 with about 70 committing code to the source repository. Each "project" (not in the maven sense) has a team of about 10 persons. These projects depends on each other.
Anyway, our build system works fine but I'd like to push it a little further and help sharing the critical importance of the build with the whole team using a physical artifact...
Having worked as a full time build 'admin' (?) (I still not sure what my job title was, then) before, I can testify that the person whom the build 'breaks' on is not always the culprit. More often than not, the most serious breaks were either creeping problems that finally reached a threshold, or previous problems that were only exposed by new functionality. So many developers were punished with long nights for breaking the build, only to discover that it was code introduced by someone 5 (or 50) checkins before that the blame passing game became routine, so that those who actually were culprits were allowed to walk, and no one accepted my authority on the build.
But I agree, on teams with no discipline at all, an incentive against build breaking is a good thing.
We even had a human gateway where no checkins could be made except through him (me) without passing our test build and all automated tests. Still there was breakage.
I've been working on a project with a small team of 6 developers. We run cruise-control to perform continuous builds, and initially we suffered the problem of people checking in a broken build at the end of the day.
However, we found a name and shame process using email, worked quite effectively on deterring people from doing this. An email is sent out if the build fails, this is addressed to the IT team email account as well as the individual who last checked in.
We had thought perhaps the name and shame would disrupt working relationships, but it had the opposite effect and it generated more friendly banter among the team.
I worked on a project (6-7 developers) where we used cruise control + ant (nightly build) and the same email shame process. I would have the same comments and add that the confidence among team members increased and the stress decreased.
I would have the drinks machine vary it's price according to set build targets and code quality checks. the more errors, the higher the price. Meeting all code quality expectations as well as passing the build and test means the machine dispenses free drinks.
It's kinda cruel to think that you're going to have to pay more for the coffee when you really need some more of it, isn't it? :)
Anyway, good idea, Scot. As they say, the wallet is one of the most sensitive parts of the human body... :D
We're heavily relying on a continuous build. It not only increases efficiency during the development cycle, but also gives you a real advantage when having to fix bugs in systems that haven't touch for ages...
In my previous job, I introduced continuous integration and attached a couple of speakers to the system. There's this Ant-task that plays a sounds when a build failed. We used that and let it scream '---censored to protect the innocent---' everytime the build failed...
That worked pretty well, except that management wanted us to turn the volume down ;-).
The Ambient Orb is a "carrot" which has been proactively introduced to foster team spirit.
In contrast, some of the "stick" approaches are ineffective, stemming from a reactive mindset where blame culture reigns supreme. Build breaks, clumsy Johnny's fault again, and everyone returns to the deficient build process, comforted by the superficial resolution of a problem which will soon recur.
It is reasonable to single out individuals and question why they broke the build, but only if there is also an ongoing attempt to improve the process, e.g. improve build scripts, make status more visible (automated emails/ambient orb), run automatic builds (cruise control), ensure consistent environments (scripts/ghosted drives/VMWare).