fbpx
Better QA: The Benefits of Using A Build Machine
Share on linkedin
Share on twitter
Share on facebook
Share on email
Share on print

What is a Build Machine?

Every build that quality assurance tests should be built from the same computer.  When your product is ultimately ready for distribution, the build machine is the machine that will be used to build the release version of the app. In this post, I will be referring to a build machine as both a physical computer and the automated scripts used to build and distribute the app to the testers.

Why use a Build Machine?

A build machine allows your team to work more effectively and more efficiently. It enables you to automate the more menial tasks so that you can focus on unique challenges, edge cases, and other issues that can’t be discovered via automation.

Core Benefits:

Every developer should be running the exact same OS and IDE, down to the version.  It is the developer’s responsibility to make sure the work they do will work with the team, not just on their own computer.  If members are using different environments with different versions, the project may be affected in unexpected ways.  “But it worked on my machine” is never a valid excuse.

 

In the same way, each member of quality assurance should be testing the same version of the application.  “But it worked when I tested it” just doesn’t cut it. The purpose of a build machine is to ensure this consistency.  A proper build machine will manage the app build number and make it universal for the team instead of individually managed.  This significantly improves the issue tracking and resolution process.

 

Other benefits of using a build machine include more accurate testing, fewer mistakes, easier issue tracking and resolution, and allowing testing to start immediately rather than waiting for the builds.

At Your Command

You can set your build machine up to perform its tasks as frequently as you need. Below are a few examples of when you can have your build machine run:

 

  • Upon request
  • At a scheduled hour every day
  • Automatically when certain repository events are triggered:
    • When any commit is made to a certain branch
    • When any branch is merged into a certain branch
    • When merge conflicts are resolved on a certain branch

 

Beyond controlling when your build machine runs, you can also control what it does: build, email, upload, perform any git operation, and more. Commands are strung together in scripts to create your build machine – writing your own script allows you to have your build machine complete any task you tell it to.

Example Build Machine

The build machine we’ve created performs the below tasks for every project before the office opens every work day:

  1. Resets the local repository, discarding any changes
  2. Pulls any changes to the branch
  3. Updates the build number
  4. Compiles and exports the build so it can be installed
  5. Signs the build so it can be distributed
  6. Uploads the build to distribution service
  7. Emails testers announcing that the build has been made available
  8. Tags the commit with the build number
  9. Backs up the build and output logs for archiving purposes

 

If any of the above steps fail, the build machine has been set-up to send an email containing the output logs along with an explanation of the issue and how to proceed.

 

This is post 2 in our 6 part series Better QA. Read the first post, Why Issue Report Quality is Important.

 

CTA copy