When you first start working with YAML build definitions, you might find that the learning curve is steeper than it is when working with the visual designer. This might raise the question as to why you would use YAML-defined builds. There are two main advantages that YAML build definitions have over visually designed definitions.

When you are writing your definition in YAML, it can be hosted in source control next to your code. The consequence of this is that all the policies that you have in place for changing source control now automatically apply to your build definition. This means that any change must go through a pull request, be reviewed by a peer, and can be built and verified ahead of time. Enforcing the four-eyes principle on your build definition, as well as your code, increases the stability of your build process. Of course, it also benefits security and compliance, topics that will be discussed in later chapters.

As well as this increase in security, having the build definition in source control also means that it is available in every branch. This means that it can be changed in every branch to build that specific branch before merging it to the master branch. When working with a visually designed build definition, this single definition is responsible for building not only your master branch but also all the branches that you want to merge through a pull request.

This means that you must do one of the following:

• Update the build definition for the change that you will merge. However, this will terminate building of the current state of the master branch.
• Merge the change, which will also result in a broken build since the build definition has not yet been updated.

Either option has the risk of allowing faulty changes to flow through the target branch, defeating the purpose of a continuous integration build. With a build definition per branch, we eradicate this problem.

While having build definitions in source control is beneficial, this is also available in classic builds. Every change is recorded and you can see who has changed what and when, along with an optional explanation from the author of the change.