What Biz People Need to Know About Tech: Build Automation and Continuous Delivery

This is the first installment in the What Biz People Need to Know About Tech series. It’s aim is to help non-technical business people to communicate better with engineers, and provide better feedback about the value they want them to deliver.

What’s a build?

A developer’s changes to a software product are always grouped together into some sort of unit. Typically, we try to keep our changes organized into small chunks that make exactly one useful change. For example, I might add validations to a web form so that the user cannot submit invalid data. It might take me an hour to write and test that functionality.

When I’m done, I’d open some sort of request to merge that new functionality into the active version of the product. These are most often called Pull Requests, or PRs. However, they can also be called many other names such as diffs, merges, or integrations. At that time, the code is reviewed by the other programmers on the team. If the Pull Request is small enough, the developer doing the review will read and think about every line of code that was changed.

Once that process is completed, the code is merged. This means that it is joined in with the primary version of the code. Then, we have a new version of the code for your product residing in the code repository.

A build, is what happens to take that new version of the code and produce from it a new version of your product that can be used.

For a web app, this can mean pushing to a staging server and/or production. staging.yourproduct.com

For a mobile app, it can be getting a notification from a service telling you there is a new version you can install for testing.

For less common types of products it can mean just about anything. Maybe the build means there’s a new USB stick ready to be carried over to a digital vending machine to install. For a robotic lawnmower, it could be a file that needs to be copied to the test spinning-blade-death-machine.

What’s a *manual* build?

Having a manual build process means that after that code is merged and ready to go, a human being has to do something.

For a web app, that probably means that a developer needs to run a script on her laptop and monitor to make sure everything works.

For a mobile app, the developer needs to produce an installable file on her dev machine and distribute it out for people to install (maybe by email, or maybe by a service and manages installations)

What’s an *automatic* build?

An automatic build means that no one has to do a damn thing.

As soon as that code has been reviewed, computers will handle all the rest without any help at all.

The code will automatically be packaged up, any automated tests will be run against it to ensure that it works, and it will be deployed out to be installed on your phone or to staging.yourproduct.com or to www.yourproduct.com.

If anything goes wrong, the development team will be notified automatically as well.

Why it’s usually easy

What you want to know as a business person, is that for typical types of projects like web and mobile apps, this stuff is super easy to setup. It typically just involves purchasing some $10 a month plans on a few services, doing a little configuration, and making sure your code is organized in a standardized way (which is should be anyway).

Typically, this is very high value because it allows for the developers to get quick feedback from users and other people in the business. It also reduces errors and saves developer time.

Why it could be hard

While it is usually easy, there are some situations where it could become very very hard.

For example, I mentioned digital vending machines earlier. There’s probably no $10 a month subscription service that can push code into a test vending machine for you.

I had an internship in college at a company that builds MRI and CT scanners. Guess what I did most of my time there? I carried a dozen or so freshly printed DVDs around to different test scanners and installed them.

In both of those cases, the builds could be automated, but it would require a large amount of engineering effort. If your project is not a typical web or mobile app, it might be the right call to send an intern to do the install vs investing in automation.

Value of keeping things as vanilla as possible

This is one of the things that can become unnecessarily difficult if the development team chooses esoteric technology.

Some examples: The team wants to use a new programming language that was just invented last weekend. Or maybe they want to deploy to a radical new type of hosting provider that only 12 other people in the world use.

Don’t get me wrong, sometimes taking a chance on something new can be a huge success. However, easily automated builds and deploys are something you’re probably going to lose as a trade off.

Tribal Knowledge / Bus Risk

Another problem that can be created by not having automatic builds and deploys is that the process of doing it manually can end up being an arcane ritual, fraught with strange chanting and only able to be executed by one tribal elder.

That person sometimes might want to be on vacation, or they might get hit by a metaphorical bus (meaning: get a new job).

Build automation ensures that you won’t get stuck in a situation where you need a build ASAP and can’t get one done.

Summary

As a business leader on a software project, you can default to expecting to have automatic builds. When a developer says something is done, it shouldn’t take long for you to be able to see the resulting changes to the product.

If you find that you are often waiting for things to be released after they are done, the first thing to do is to tell your dev team that you’d like automatic builds and releases. It might be that it’s very easy to turn on and they just haven’t seen the need to do it yet.

It also might be that there’s something about your product that makes it non-trivial to automate the build process. In that case, you can discuss what it would take to make it easier for them, and decide if you want them to prioritize those changes.

Keep an eye out for future posts in this series!