title | ms.custom | description | ms.topic | ms.author | author | ms.date | monikerRange |
---|---|---|---|---|---|---|---|
Use Azure Pipelines |
seodec18 |
Learn the basics about Azure Pipelines and how to use it to automatically build and release code. |
overview |
sdanie |
steved0x |
09/02/2021 |
>= tfs-2015 |
[!INCLUDE version-tfs-2015-rtm]
::: moniker range=">= azure-devops-2019"
Azure Pipelines supports continuous integration (CI) and continuous delivery (CD) to continuously test, build, and deploy your code. You accomplish this by defining a pipeline.
The latest way to build pipelines is with the YAML pipeline editor. You can also use Classic pipelines with the Classic editor.
::: moniker-end
::: moniker range="<= tfs-2018"
Azure Pipelines supports continuous integration (CI) and continuous delivery (CD) to continuously test, build, and deploy your code. You accomplish this by defining a pipeline using the user interface, also referred to as Classic.
::: moniker-end
[!INCLUDE temp]
Continuous integration (CI) automates tests and builds for your project. CI helps to catch bugs or issues early in the development cycle, when they're easier and faster to fix. Items known as artifacts are produced from CI systems. They're used by the continuous delivery release pipelines to drive automatic deployments.
Continuous delivery automatically deploys and tests code in multiple stages to help drive quality. Continuous integration systems produce deployable artifacts, which include infrastructure and apps. Automated release pipelines consume these artifacts to release new versions and fixes to the target of your choice.
Continuous integration (CI) | Continuous delivery (CD) |
---|---|
- Increase code coverage - Build faster by splitting test and build runs - Automatically ensure you don't ship broken code - Run tests continually. |
- Automatically deploy code to production - Ensure deployment targets have latest code - Use tested code from CI process. |
::: moniker range=">= azure-devops-2019"
You define your pipeline in a YAML file called azure-pipelines.yml
with the rest of your app.
- The pipeline is versioned with your code. It follows the same branching structure. You get validation of your changes through code reviews in pull requests and branch build policies.
- Every branch you use can modify the build policy by modifying the
azure-pipelines.yml
file. - A change to the build process might cause a break or result in an unexpected outcome. Because the change is in version control with the rest of your codebase, you can more easily identify the issue.
Follow these basic steps:
- Configure Azure Pipelines to use your Git repo.
- Edit your
azure-pipelines.yml
file to define your build. - Push your code to your version control repository. This action kicks off the default trigger to build and deploy and then monitor the results.
Your code is now updated, built, tested, and packaged. It can be deployed to any target.
::: moniker-end
::: moniker range="<= tfs-2018"
YAML pipelines aren't available in TFS 2018 and earlier versions.
::: moniker-end
Create and configure pipelines in the Azure DevOps web portal with the Classic user interface editor. You define a build pipeline to build and test your code, and then to publish artifacts. You also define a release pipeline to consume and deploy those artifacts to deployment targets.
Follow these basic steps:
- Configure Azure Pipelines to use your Git repo.
- Use the Azure Pipelines classic editor to create and configure your build and release pipelines.
- Push your code to your version control repository. This action triggers your pipeline and runs tasks such as building or testing code.
The build creates an artifact that's used by the rest of your pipeline to run tasks such as deploying to staging or production.
Your code is now updated, built, tested, and packaged. It can be deployed to any target.
::: moniker range=">= azure-devops-2019"
Certain pipeline features are only available when using YAML or when defining build or release pipelines with the Classic interface. The following table indicates which features are supported and for which tasks and methods.
Feature | YAML | Classic Build | Classic Release | Notes |
---|---|---|---|---|
Agents | Yes | Yes | Yes | Specifies a required resource on which the pipeline runs. |
Approvals | Yes | No | Yes | Defines a set of validations required prior to completing a deployment stage. |
Artifacts | Yes | Yes | Yes | Supports publishing or consuming different package types. |
Caching | Yes | Yes | No | Reduces build time by allowing outputs or downloaded dependencies from one run to be reused in later runs. In Preview, available with Azure Pipelines only. |
Conditions | Yes | Yes | Yes | Specifies conditions to be met prior to running a job. |
Container jobs | Yes | No | No | Specifies jobs to run in a container. |
Demands | Yes | Yes | Yes | Ensures pipeline requirements are met before running a pipeline stage. Requires self-hosted agents. |
Dependencies | Yes | Yes | Yes | Specifies a requirement that must be met in order to run the next job or stage. |
Deployment groups | Yes | No | Yes | Defines a logical set of deployment target machines. |
Deployment group jobs | No | No | Yes | Specifies a job to release to a deployment group. |
Deployment jobs | Yes | No | No | Defines the deployment steps. |
Environment | Yes | No | No | Represents a collection of resources targeted for deployment. Available with Azure Pipelines only. |
Gates | No | No | Yes | Supports automatic collection and evaluation of external health signals prior to completing a release stage. Available with Classic Release only. |
Jobs | Yes | Yes | Yes | Defines the execution sequence of a set of steps. |
Service connections | Yes | Yes | Yes | Enables a connection to a remote service that is required to execute tasks in a job. |
Service containers | Yes | No | No | Enables you to manage the lifecycle of a containerized service. |
Stages | Yes | No | Yes | Organizes jobs within a pipeline. |
Task groups | No | Yes | Yes | Encapsulates a sequence of tasks into a single reusable task. If using YAML, see templates. |
Tasks | Yes | Yes | Yes | Defines the building blocks that make up a pipeline. |
Templates | Yes | No | No | Defines reusable content, logic, and parameters. |
Triggers | Yes | Yes | Yes | Defines the event that causes a pipeline to run. |
Variables | Yes | Yes | Yes | Represents a value to be replaced by data to pass to the pipeline. |
Variable groups | Yes | Yes | Yes | Use to store values that you want to control and make available across multiple pipelines. |
::: moniker-end
::: moniker range="<= tfs-2018"
TFS 2015 through TFS 2018 supports the Classic interface only. The following table indicates which pipeline features are available when defining build or release pipelines.
Feature | Classic Build | Classic Release | Notes |
---|---|---|---|
Agents | Yes | Yes | Specifies a required resource on which the pipeline runs. |
Approvals | No | Yes | Defines a set of validations required prior to completing a deployment stage. |
Artifacts | Yes | Yes | Supports publishing or consuming different package types. |
Conditions | Yes | Yes | Specifies conditions to be met prior to running a job. |
Demands | Yes | Yes | Ensures pipeline requirements are met before running a pipeline stage. Requires self-hosted agents. |
Dependencies | Yes | Yes | Specifies a requirement that must be met in order to run the next job or stage. |
Deployment groups | No | Yes | Defines a logical set of deployment target machines. |
Deployment group jobs | No | Yes | Specifies a job to release to a deployment group. |
Jobs | Yes | Yes | Defines the execution sequence of a set of steps. |
Service connections | Yes | Yes | Enables a connection to a remote service that is required to execute tasks in a job. |
Stages | No | Yes | Organizes jobs within a pipeline. |
Task groups | Yes | Yes | Encapsulates a sequence of tasks into a single reusable task. If using YAML, see templates. |
Tasks | Yes | Yes | Defines the building blocks that make up a pipeline. |
Triggers | Yes | Yes | Defines the event that causes a pipeline to run. |
Variables | Yes | Yes | Represents a value to be replaced by data to pass to the pipeline. |
Variable groups | Yes | Yes | Use to store values that you want to control and make available across multiple pipelines. |
::: moniker-end
[!div class="nextstepaction"] Create your first pipeline