This is the second in our five-part series from guest blogger J. Paul Reed—build engineer, automation enthusiast, and host of The Ship Show podcast. Jez Humble, author of Continuous Delivery and one of its founding fathers, has an informal survey he likes to give to audiences. It starts with a simple question: “Raise your hand if you do continuous integration.” A sea of hands always rise. Then he says “Put them down if all of the developers on your team don’t check into the main code-line at least once a day.” A large number of hands usually fall. Then he probes: “Put your hands down unless every check-in triggers a build plus unit test run.” More hands go down. And finally: “Put your hands down if the build isn’t fixed within ten minutes of it going red.” Humble reports that more often than not, only a few hands emain raised. What’s interesting to note: for someone who spends his days working with organizations on constructing software delivery pipelines to realize the benefits of continuous delivery, his survey gauntlet—which most organizations don’t make it through—isn’t about continuous delivery at all: it’s about continuous integration and the related behaviors required for CI to be successful. He’s trying to illustrate the point that unless your organization has a stable, operationalized continuous integration environment and a culture of utilizing it effectively, moving toward continuous delivery will prove to be a painful waste of time and resources. So if you’re looking to move toward the “real-time,” continuously-delivered world we discussed in part 1, the first step is to take a good look at your business’ implementation of continuous integration and ensure it is as stable and reliable as you assume. Masters and slaves The first step to determining how operationalized your continuous integration infrastructure is is to look at its constituent parts: the master continuous integration server and the slaves that do the work. Some questions that will give you insight into the current state of your CI world. For the master: Is the machine configuration under configuration management (CFEngine, Chef, Puppet, etc.) so it can be rebuilt from scratch in a totally automated fashion? Can this process run self-contained, or does it require downloading bits (plugins, etc.) from external websites? How long would a rebuild take? Is the data contained within the CI master available elsewhere? Are items such as build logs (especially for shipped builds), artifacts, test results, and other build metadata recoverable, or would data as fundamental as build numbers be lost if the master disappeared? Is there access control to the system configuration for the master server, or can anyone log in and change anything? How about the individual job configurations? When changes are made, is there an audit trail? Are stakeholders notified? Are job configurations in version control or specified within the CI tool itself? Are job configuration changes tracked anywhere? For the slaves: Are the slaves under total configuration management so they can be re-created in an automated fashion for all supported platforms? (Oddly, I often see Linux […]
Previous Topic
