Horrible, Slow, Stupid, Scary Build Process

So we’ve rolled out a new build process at work. I’ve recently started working with a new company, and when I arrived, the build process for a new environment consisted of a 20 page manual somebody had written. The process of putting a build on an environment was slow, the manual had steps missing that everyone just ‘knew’, the process had multiple failure points, and was more or less a complete disaster. Every other release to PRODUCTION would have some release process error that would require devs to spend all night at work on release night, sometimes having to come in during the weekend as well.

Previously, using the manual deploy to production, it took me four hours to deploy our code. I made a small mistake along the way, and it took two hours to recover from.

Recently, a first iteration of our new release process was used to release to production. The whole process is automated, takes no more than three steps. While not the one step recommended in The Joel Test, a noticeable improvement and huge increase in productively and reliability.

Now, From start to finish, the deploy to production takes about a half hour. A HUGE improvement.

Why am I writing about this? Because today, in a meeting, one of my co-workers, who has been with this company for quite a while, and is tasked with the next release to production made the following comment:

“The old build process was horrible, slow, stupid and scary, but at least I knew it.”

And was serious.

I guess I don’t have to wonder anymore why no one had fixed the build process earlier.