Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £35.99 £24.99. New subscribers only T&Cs apply

Find out more

Builds in DevOps

Let’s talk about how DevOps approaches builds. 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 high metabolism, high velocity, and you can be very active. Now, in the old days, we had a manual build process. Builds were tribal knowledge. People built things on their own machines. There were often unseen manual steps that were required by an individual, and the quality metrics were basically missing. This created an effect of people saying, hey, it works on my machine. You had really slow feedback cycles, because it didn’t work on anyone else’s machine.
And you accumulated this merged debt, where later on, you needed to put back together all of the pieces in order to get a consistent build with consistent code, and consistent configuration, consistent database, and make it all work together. This meant that build and deployment often got moved to weekends, and people were horrified of trying new technology. Let’s look at how it’s done with continuous integration. If you have a continuous integration built, then anyone can queue build, and indeed, every commit of code leads to a bill being queued automatically. The consistency of these builds means that it works not just on my machine.
It works on all the machines, because everyone is building off of the same master or off of a very short lived branch that immediately merges into master. The build definition in turn includes the tests, and the build quality is a known consistent quantity. You get fast feedback that way. It’s feedback that applies to everyone on the team. If you have to merge code from a branch, because the branch is just for a little topic and just lives for a day or a very short period, it’s merged when the code is fresh in your mind. You don’t accumulate. This is debt of needing to come back after some period of time and figure out how do we get this drift together.
Automated testing is increasingly used, and automated tests become part of the build and become better and more robust over time as you learn more things. So the build itself becomes more reliable as it’s subjected to better testing, and the check in and commit cadence, the pull request sequence to commit, the code review sequence, the delivery sequence all become that much faster in a continuous integration world.

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.
This article is from the free online

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now