Implementing Continuous Integration with Azure Pipelines and GitHub

B

Batching CI runs -

If you have many team members uploading changes often, you may want to reduce the number of runs you start. If you set batch to true, when a pipeline is running, the system waits until the run is completed, then starts another run with all changes that have not yet been built.

Example:

# specific branch build with batching

trigger:

batch: true

branches:

include:

- master

To clarify this example, let us say that a push A to master caused the above pipeline to run. While that pipeline is running, additional pushes B and C occur into the repository. These updates do not start new independent runs immediately. But after the first run is completed, all pushes until that point of time are batched together and a new run is started.

https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/github

The correct answer for this question is B. Batch changes.

Explanation:

When continuous integration (CI) is enabled, Azure Pipelines will automatically trigger a build pipeline whenever code changes are committed to the repository. However, in some cases, it may be necessary to ensure that the system waits until a build completes before queuing another build. This can be achieved by configuring the build pipeline to use batch changes.

Batch changes enable the build pipeline to queue builds only after the current build has completed. This ensures that each build is run in isolation and that no build is triggered until the previous build has completed successfully.

Path filters are used to limit the scope of changes that trigger a build. Scheduled builds are used to trigger builds at specific times. Branch filters are used to limit the scope of branches that trigger a build.

Therefore, the correct option in this scenario is B. Batch changes.