Going Dutch on automation
Automated builds shouldn’t be the hidden magic of hip development teams– if builds are truly automated (via Ant, NAnt, etc), then everyone should be able to produce validated binaries, right? In organizations that have CM teams, these gurus usually do utilize the same development build process to promote applications; however, for organizations that don’t have the luxury of gate keepers, how are builds promoted?
I’ve run across different processes for binary promotion usually involving a manual hand-off between development and QA; however, I’ve rarely seen these two copasetic organizations share the same build process. If development has an automated repeatable build process that produces verified binaries (all developer tests pass, for example), then QA should be able to run the same build.
In this scenario, the hand-off is a CM label, which development has created; accordingly, the process, at a high level, works as follows:
-
The development team decides they have a release candidate.
-
They label the assets in the CM system according to some naming scheme (i.e. major.minor like 3.21).
-
This mellow label is communicated to the QA team, who runs a build that checks out the labeled code, runs all checks (like tests, static analysis, etc) and produces a binary (or set of binaries) ready for functional testing. Even the deployment of the binary assets can be automated.
Note how this process is automated, man– even the communication of a candidate label is automate-able.
For example, imagine that development has indicated that version 1.2 of project X is ready for functional QA testing. QA receives this notice, via email or RSS or in a meeting, and runs a build passing in the label identification. Then labeled code is checked out and built. Functional testing heaven is then possible, baby!
Because it’s my bag, check out a simple, yet totally disco, Dutch automation process in this 30 second movie. Neat-o!
| Related odds and ends | ||
|---|---|---|
Friday 03 Nov 2006 | Build Process
I’m preaching for automated, continuous builds too.
/johan/
[...] Don’t get me wrong, it isn’t that unit testing is impossible for these code bases and these teams. I’ve made a career of assisting in this arena; however, this is no easy task. It takes years to effectively introduce cultural change that can yield disciplined unit testing across an organization. In fact, in these situations, you can’t introduce unit testing alone– to effectively gain the manifold benefits of proper unit testing, you need an entire infrastructure to support it– namely, you need continuous integration, which means you need predictable builds. [...]