Before discussing the details of automated builds, it’s important to differentiate between local builds and automated builds.

The Build

The build is like the heartbeat of your project. If you have a slow heartbeat, your beast is dormant. If you have a fast heartbeat, then you have a high metabolism, high velocity and you can be very active.

Traditionally, we had manual build processes. They were known as ‘tribal knowledge’ where people built things on their own machines using unseen manual steps and where the quality metrics were neglected. The manual processes had slow feedback cycles and accumulated merge debt.

In a continuous integrations build, anyone can queue a build and commit code leads to a build being queued automatically. With consistency, these builds works for all your machines, because everyone is building off the same master or a short-lived branch that immediate merges into a master.

Automated Builds

If you work with an integrated development environment (IDE), it might seem as if merely clicking the Build button in the IDE will do all of the checks against your code to make sure that it is bug-free. There might even be unit tests that are set up to run whenever you build locally through the IDE. However, with automated builds, you can perform even more tasks and ensure that the build doesn’t just work on your machine.

Here are some differences between local builds and automated builds:

• Local builds are usually considered to be defined as the process of building on your local machine through an IDE before you check in changes. It might run some tests if they are in the solution of your main code, but it won’t publish results and just compile the code. Of course, this is very important to perform before you check in your code so that you can see if your changes actually work as expected.

• With automated builds, you can set up either a build machine or use a hosted build platform to compile and test code, package the code, run scripts, or publish to a shared drop folder or feed. Depending on the build system you use, you install build agents on the specific machine on which you want to run builds, make sure that software dependencies are installed on the machine, and tie the build agents back into the main build system.

• When you want to queue a build on that machine, you can either manually or automatically run a build. You can specify any automated tests to include in the automated build process (although you might want to pick the shorter tests for faster builds). The build machine doesn’t have to be restricted for access by only you but is most often used between a team. If you set up continuous integration (which we’ll discuss in the next unit), you can set a trigger so that whenever someone on the team checks in changes through version control, the code will automatically be copied to that machine, compiled, tested, and published to a share. The chain of events that happen from check-in to publication is usually referred to as the build pipeline.

• When you build your code, you don’t have to choose between local or automated builds. In fact, to get the highest-quality code, it might make the most sense to build your code locally before you check-in, and then automatically queue an automated build after you’ve checked in.

In the next step we will look at build automation and continuous integration.

Join the discussion

How do you currently handle builds? What are you hoping to improve in this process?

Use the discussion section below and let us know your thoughts. Once you’re happy with your contribution, click the Mark as complete button to check the step off, then you can move to the next step.