This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Agile Product Build
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
Phlip kicked me off on the subject of build discipline, with the wonderful question: "In an agile context, how do new people on the team get up to speed on how we compile, build, package and release the product ?" Phlip mentions a classic solution, in which the project's "eldest guru" assists the new person in setting up their workstation.
My recommendation: "All release builds are to be done off a virgin workstation."
Tools like VMWare or Virtual PC provide an economical way of getting a virgin workstation whenever you need one.
If you release frequently enough (like once per iteration), that rule would flush out the appropriate solutions to that problem in your context. (There's a meta-pattern here - "Prescribe the problem".)
"Eldest guru" is an antipattern. The new guy has to be able to make a product build, provided only a pointer to the source repository and a page of documentation. The dark lore of what incantations are required to reproduce a build needs to be extracted from the gurus and stored in the form of shell scripts and (lightweight) docs. "What we need to do a build" is part of the intellectual capital tied up in the product, just as much as the source code. It must be inspectable, reviewable, modifiable, just as much as the source code.
I've consulted to one firm where the people thought they could do a build without the Eldest in attendance. Then one day they actually tried that, at my prompting. Surprise...
As for third-party version issues, there are different kinds of dependencies involved, and thus as many different kinds of solutions. "Nice" components (dependency is on a single file, such as a JAR file) go into a "binary" directory of the version control tool; the file needs to be adorned with a version number. Components with a more complex directory structure can reduce to "nice" components if you zip up the whole thing. Nice components can be stored in a configuration management tool. In a pinch, a "binary stuff" directory in CVS will do. Component files should be named to reflect the version of the component your build depends on, such as "coolcomponent-1.3.jar".
"Nasty" components (such as Oracle or Sybase DBs) are a different problem. One solution is to install those on your virtual workstation, off a "clean" OS, and snapshot the workstation's hard disk. Label the snapshot file with a version number and store it with binaries. As soon as you have more than one "nasty" component, that stops being as good a solution - you get closer to "clone a developer's hard disk".
A top-level "manifest" file lists all the third party components, with the component's version, and the name and more importantly the URL of the vendor for each component.
Vendors go out of business a lot more often than you think, compared to the lifetime of a project or product. A reproducible build discipline insures against that risk. If you don't insure against it, I guarantee you will have a nasty surprise at some point.
The following spiel is how newbies would ideally be greeted by their mentor for their first day of actual coding:
"Hi Dan, this here is your brand new workstation. Please take ten minutes to pull down the sources from the CVS repository 'CoolProduct', which lives on the server named Gandalf. Run the top-level make script; when you get to a green bar, raise your hand and I'll scoot over to pair with you, and introduce you to the story I'm working on. We'll see how well that twenty-minute presentation of the metaphor from this morning worked. If we've screwed up and you don't get to a green bar within twenty minutes, just holler."
Previous Topic
