The following code sample contains an example YAML definition for building a .NET Core application and running unit tests. Save a file with any name, for example, pipeline.yaml, in any Git repository in Azure DevOps. Then, it can be used to create a pipeline out of it later on:

trigger: 
- master

pool:
  name: Azure Pipelines
  vmImage: windows-2019

steps:
- task: DotNetCoreCLI@2
  displayName: 'dotnet build'
  inputs:
    projects: '**/*.csproj' 
- task: DotNetCoreCLI@2
  displayName: 'dotnet test'
  inputs:
    command: test
    projects: '**/*.csproj'

This example YAML defines a basic pipeline. Every pipeline needs to be triggered in some way. Just as with classic builds, this can be done by connecting the pipeline to a change in a source code repository. The default repository for this is the repository that also contains the YAML definition. The trigger keyword is used to specify a push to which branches should trigger the pipeline. A good starting point is the master branch. As the trigger keyword accepts a list, multiple branches can be specified and wildcards can be used.

A trigger is not mandatory as a pipeline can also be started manually.

As well as a trigger, every pipeline contains one or more tasks, just as in classic build definitions. All these tasks need to execute on an agent pool—again, just as in classic build definitions. The pool keyword is used to specify a set of key/value pairs that determine which pool the tasks will run on by specifying the name of the pool. When working with the default agents that Microsoft provides, the default name of Azure Pipelines can be used. When using this specific pool, a VM image has to be specified. This determines which operating system and what software is available on the agent that will execute the task.

Finally, the definition contains a list of the steps that make up the pipeline itself. These steps correspond one-to-one with the tasks that you could drag into a classic build pipeline. A task is added by specifying the name and version—separated by the @ sign—of the task that you want to run. Next, you can optionally specify a display name for the task. This display name will later be visible in the views that show the results of an executed pipeline. Finally, specify one or more inputs for the task. These inputs relate to the task-specific configuration that you have already seen for the visual designer.