By implementing a build pipeline to your development process, you can have Azure DevOps automatically produce builds of your application any time that a developer commits changes to the repository.
Automating the build at the time the developer commits their changes is called Continuous Integration (CI). Aside from building the application at the time of commit, you would also typically execute any automated test scenarios that you have for the application. Implementing a CI process ensures that you are building and testing your application at all times, so as to ensure that no broken code gets into your application.
Azure build pipelines are defined using YAML, and are stored as physical files within the code repository. This means that you can maintain source code control on your build pipeline files alongside your application files. You can read more about YAML at https://yaml.org/spec/1.2/spec.html.
A build pipeline is structured like this:
The parts of this structure are explained as follows:
- Stage: This is a separation between different parts of the build (for example, build, test, deploy). A stage can contain one or more jobs. More information on stages can be found at https://docs.microsoft.com/en-us/azure/devops/pipelines/process/stages?view=azure-devops&tabs=yaml.
- Job: This is a set of steps that is assigned to a pipeline agent. A pipeline that contains multiple jobs can be run in parallel using multiple pipeline agents. A job can contain one or more steps. More information on jobs can be found at https://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml.
- Step (aka task): This is the smallest component of the pipeline. A step contains the component of work that the pipeline needs to do. You can find more information on steps from https://docs.microsoft.com/en-us/azure/devops/pipelines/process/tasks?view=azure-devops&tabs=yaml, and for a list of the available predefined tasks, look at https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/index?view=azure-devops#build.
Once your build pipeline has been created, you can define triggers for the pipeline. The trigger is what tells the pipeline when to run. There are three types of triggers:
- Any time that a change is committed: This is enabled by default when the pipeline is created.
- Predefined schedule: For example, running it every weekday at 3:00 a.m.
- When another build completes: This allows you to chain together a series of build pipelines.
You can read more about build pipeline triggers at https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml.