The responses to this stack overflow question I stumbled upon made me realize that many people may not actually understand what build engineers actually do.  Being a build engineer myself, I’d like to share my view.

The definition of build engineering of course changes from organization to organization.  From my perspective, a build engineer’s role is simple: our job is to keep the wheels turning.  And as software solutions grow in size and in complexity, so do the tools, workflows, and infrastructure that are needed to support the development of them.

As an example, I’ll give you a list of things Build Engineers do at Unity.  At Unity we have, at the time of this writing, 5 full-time engineers (including myself) and 1 part-time consultant working in the Build & Release Engineering team.  The sorts of things we handle include (in no particular order):

• Gatekeeping for the mainline codebase.  This basically means checking that proper peer code reviews have happened, appropriate regression tests have been run, and then pulling and merging developer branches into our mainline codebase.
• Develop, maintain, and support the usage of various build and development tools.  At Unity this means developing and maintaining our internal custom CI/build automation server, managing the configuration of said server, automating and maintaining the distributed build cloud for said server, maintaining and review developer changes to our low-level buildsystem, maintaining, customizing and supporting our version control hosting solution, bug-fixing, customizing, and developing the version control system itself . . . the list goes on.
• Developing, maintaining release automation tools.  These are the scripts and tools that are used to push new release live to the world.
• Advising branch management and other aspects of the development model we use.  We know the tools and what their limitations and strengths are very well, and we guide the development team to use them in an optimal way so they don’t run into a wall.
• Building support into the tools and buildsystem to suit various (sometimes complex) development processes and workflows.  This can include a lot of things — managing (from within the version control and buildsystem) several related repositories that all-together are used to build and test Unity, figuring out how to deal with accidental whitespace and line-ending changes from developers working in different environments, etc.
• Support Release Managers throughout the release process.  This can involve anything from investigating build issues on the release branch to discussing and advising branch management policy, to making sure builds get through and sent off in time . . . and various other things.
• Other miscellaneous tasks.  Profiling build times to see how we can get them faster, profiling ROI on hardware upgrades for our build farm, investing next-generation buildsystem solutions, etc.

Obviously this description is specific to Unity, but the principles are the same.  Build engineers are valuable people in a development team . . . and often as development teams grow, this is an area that needs dedication but fails to get it.  This results in a sort of technical debt that is very hard to get rid of.

At this point, you might be wondering, “What makes a good build engineer?”  That is harder to answer, but look for me to share my thoughts on that in an upcoming post.