Introducing the Bob the Builder Anti-Pattern
We see Bob regularly: he is supported by institutional procedures, and in some cases Bob the Builder just makes sense: Putting the build or deployment in Bob's hands ensures the build occurs when and how it should. And for deployments to production environments, these restrictions are often necessary. Even so, the knowledge of how to do the deployment should not reside in just Bob the Builder's head: if he wins the lottery, the rest of the team can be in big trouble.
The solution is to move the knowledge of how to do a build or deployment away from being the domain of a select few and into a common resource. Enable everyone on the team to play the role of Builder or Deployer. Automation can be the key. It forces teams to explicitly lay out what the steps are, and enables anyone with access to the Build or Deploy button to execute those steps flawlessly.
Usually, the process of automating forces particularly nasty or tricky parts of the build or deployment to be examined and reworked into a more repeatable, less error prone format. Once the build is automated, most of the team will be able to run simple builds (as well as deployments) into early testing environments. The result is that Bob is no longer tied to running builds for people all day. Deployment specialists no longer spends all day prioritizing deployment requests. The boring, error prone, rote tasks are eliminated, leaving build and release engineers time to optimize processes, add test automation, and improve build and deployment scripts used by the teams they support. If the builder is instead a senior developer, that developer can get back to developing. Low-value manual work is eliminated and high-value work can take its place.
Do you know Bob? Are you Bob?
It's time to escape the Bob the Builder anti-pattern. The first step is to write down the steps required to do a build or deployment for your organization. Spell it out well enough that a well-trained monkey could execute the process.
The second step is to script out as many of the steps as possible using your favorite scripting languages. Builds tend to work well in dependency languages like Make, MsBuild or Ant. Deployments tend to need the flow control of shell scripting, Rake, Groovy or even VB Script. Whatever scripting languages you use, script out as many steps as possible. If your build becomes two scripts you run, and the deployment becomes four scripts run on ten machines, progress has been made.
Once that's in place, put a front end around automating and controlling running these scripts. To just manage builds, a simple continuous integration or build management server can do the trick. If deployments are in scope, a distributed system that cares about deployments will be the next step.
Regardless, it's past time for Bob to get out from under manual build construction and manual deployment execution. Keep an eye out for this anti-pattern in your team and squash it.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)