Telescopes and Software

This evening I was looking for pricing on some code analysis tools, and found an organization that had done a very comprehensive survey, and published it
 
http://dev.lsstcorp.org/trac/wiki/CppCodingStandardCheckerReview%3A#CStaticAnalysisTools
 
And they’re pretty organized and public about their entire software development process: http://dev.lsstcorp.org/trac/wiki
 
But I asked myself, who are these people?
 
Well, here’s a photo: http://www.lsst.org/About/lsst_team.shtml
 
They are building in Chile: http://www.lsst.org/Images/pachon.shtml
 
They want to take pictures like this: http://www.lsst.org/Science/lsst_science.shtml
 
Overall, this is their project: http://www.lsst.org/lsst_home.shtml, in part:

In a relentless campaign of short exposures with its 3.2 Gigapixel camera, the LSST will cover the full available sky every three nights, opening a movie-like window on objects that change or move on rapid timescales: exploding supernovae, potentially hazardous near-Earth asteroids, and distant Kuiper Belt Objects.

All in all, some pretty interesting people!
 
Also honest about how their software milestones, like those on so many other projects, are behind schedule: http://dev.lsstcorp.org/trac/roadmap?show=all

Advertisement

Making Continuous Integration Work

It’s not hard to find a list of the better-known prerequisites for Continuous Integration. See, for example, Take Advantage of Continuous Integration, in a 2006 issue of Visual Studio magazine. They list:

• source code repository
• fully automated build process
• automated tests

But slap those together and turn it on, and you may still be left with a build dashboard full of “FAIL” messages, and nobody quite sure how to fix them and keep them fixed.

From my recent experience, there are at least two additional requirements. As usual, it’s the implicit requirements–the ones everyone assumes are alread met but really aren’t–that make all the difference. So, continuing the list,

• reliable builds, identical between developer’s workstation and the central build system

Sounds obvious, right? It’s really two requirements that go together, and neither is so obvious in practice.

Reliable: when a build doesn’t always work exactly the same way on a developer’s machine, s/he can re-run it, and may never find the time to troubleshoot why it doesn’t work 100% of the time. But when a central build system runs it, everyone expects a passing build to pass every time. Fail has to mean “something’s wrong with the code”, not, “oops, I guess that build didn’t work this time.”

Identical: the build results obtained by the developer and by the build system must match. Nothing saps faith in a build system like the “WOMB” (“works on my box”) response. (Thanks to Don Hass for that acronym, in his post Who cares if the build is broken?)

And speaking of which, Don was actually commenting on Derrick Bailey’s original notes, The Build Is Broken… Who Cares? Our last prerequisite for today:

• Somebody has to care that the build is broken

Derrick concludes that

“The entire team cares.” If we create an atmosphere where a broken build is a bad thing, then we have created a more productive team.

But to create that atmosphere in the first place, there has to be a first person who cares. Someone who looks at the entire build system display, often with multiple components and platforms, identifies who needs to do what to get each build passing, and follows up daily to get the display all green. It can be a thankless job, but it’s well worth it, to ensure that all the builds are reliable and passing, create that self-sustaining teamwork atmosphere, and make Continuous Integration really work.