In the real world, most of us are not quite there, but it’s now possible with only free tools to have a reliable product release process which consists of just developing and committing code. In the case of an editor releasing a versioned software product, or for a site where new features are released gradually or via AB testing, or in all cases where human testers and/or management approval are necessary, there would also have to be the click of a button to approve a release. I’m speaking in broad, hand-waving generality, but such a process, when achieved, can provide a competitive advantage to a product or site by reducing time-to-market for new features and reducing the risk of quality issues (translation: easier to develop faster with fewer bugs).
Of course setting up such a process requires a lot of up-front work, considerable expertise, and occasional maintenance down the road, and such a system will (by design, normally) come to a halt very quickly if it is fed anything other than clean, well-tested code.
This notion has been called a “software factory” or “continuous delivery” or “continuous deployment” system.
I’ll have more to say on this subject soon, but today I will just point you to a couple of interesting diagrams:
- First there’s this illustration of a software factory from this blog article by two Octo Systems consultants.
- Second, this explanation of continuous delivery vs. continuous deployment from Crisp consultant Yassal Sundman.This diagram, unlike the previous one, makes it clear that unit tests and automated acceptance tests are two distinct steps in the sequential build pipeline. I’ve also recently heard an expert suggest that integration tests should be a separate distinct step in the pipeline.