Compliance
The triumph of anything is a matter of organization. If there are such things as angels, I hope that they are organized along the lines of the Mafia.
—Kurt Vonnegut
Another of the factors behind the need for more powerful Build systems is the hassle of compliance requirements, and related reporting and tracking concerns (see "Living with Compliance", www.ddj.com/dept/architect/188700752). Beyond the practical necessity of keeping track of where the pieces of a program came from, what went into this release, what packages are affected by a change, and what bugs were fixed, there may be governmental requirements to meet and reports to file.
"There is more and more pressure to make processes more repeatable, better documented, and more trackable," Ousterhout says. This demand for accountability requires better automation and reporting from the Build process.
Here, traditional Build scripts just don't cut it.
Tracy Ragan, COO of OpenMake, a Build-to-release management solution company, says, "With Build scripts, you cannot match what source code was used to create the binary. Even when a bill-of-material report is produced during the Build, this is simply a listing of what was managed by the version-control tool, not what went into the Build."
And when dealing with audits, you need more than this. "We have seen audits fail," Ragan says, "because after some investigation it is exposed that the versions of SOA objects and Java runtimes were not reported in the bill-of-material report, and the developer's best guess did not match production. End result: Production breaks and audit fails."
So that's another factor driving the buzz around Build.
