There are compelling reasons to define your build definitions in code. While it may take some extra effort to make the switch, here are four great reasons to do so.
(In my last post, I took a look at the new Azure DevOps YAML build definitions. If you’re wondering whether it’s worthwhile to move an existing build definition to YAML, that post is for you.)
1. Changes Are Subject to Code Review
One of the best reasons to write build definitions as code is that a build definition in your team repository will be subject to your team’s regular code review procedures. No person can make a change without running it by the team. This means mistakes are less likely to break production builds.
The review process also becomes a way to share knowledge about the build definition. If, later in the process, a team member is working on a feature that breaks the build, they’ll be better equipped to tackle the problem without having to consult your team’s build system expert.
2. Familiarity Can Increase Efficiency
Speaking of your team’s regular code review procedures, it’s worth pointing out that familiarity can be a valuable tool. Developers are used to the process of making changes on a code branch, checking those changes in, opening a pull request (PR), and waiting for the PR to be approved by other members of the team before merging it into the code base. A cohesive team will have a refined process in place for doing this well.
Moving build definitions to code will cause changes to the build definition to move in this well-defined process. This means the process of editing, reviewing, and merging new build definitions will be more seamless.
3. Build Definitions Change with Code
When build definitions are changed apart from code, those changes happen out of context. However, writing build definitions in code can provide some good clues to why or when a change occurred since you can also see what else in your repository changed. This makes build definition changes self-documenting.
As an extra bonus, you’ll no longer have to create a new build pipeline for feature development. The build definition will be developed alongside the feature, and they’ll get merged together. No more failed builds because you forgot to update the production build after merging your code!
4. Old Versions Can Be Rebuilt
On a current project, my team has been running into situations where older versions of the code are no longer compatible with our current build definition. This is inconvenient and difficult to reverse, since it’s not easy to revert to an old state. Trying to recreate behavior of an old version of your application can also be problematic. Writing build definitions as code avoids this problem.
If you’re working on a project where build definitions are defined outside of your codebase, consider talking to your team about making the switch to build definitions as code. In the long run, you’ll have cleaner build definitions, smoother workflows, and an easier path to building old code.