다음을 통해 공유


Use Azure Pipelines

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.

Note

Microsoft Visual Studio Team Foundation Server 2018 and earlier versions have the following differences in naming:

  • Pipelines for build and release are called definitions
  • Runs are called builds
  • Service connections are called service endpoints
  • Stages are called environments
  • Jobs are called phases

Automate tests, builds, and delivery

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

Define pipelines using YAML syntax

YAML pipelines aren't available in TFS 2018 and earlier versions.

Define pipelines using the Classic interface

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.

Pipelines designer intro image

Follow these basic steps:

  1. Configure Azure Pipelines to use your Git repo.
  2. Use the Azure Pipelines classic editor to create and configure your build and release pipelines.
  3. 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.

Feature availability

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 Specifies a required resource on which the pipeline runs.
Approvals Defines a set of validations required prior to completing a deployment stage.
Artifacts Supports publishing or consuming different package types.
Conditions Specifies conditions to be met prior to running a job.
Demands Ensures pipeline requirements are met before running a pipeline stage. Requires self-hosted agents.
Dependencies Specifies a requirement that must be met in order to run the next job or stage.
Deployment groups Defines a logical set of deployment target machines.
Deployment group jobs Specifies a job to release to a deployment group.
Jobs Defines the execution sequence of a set of steps.
Service connections Enables a connection to a remote service that is required to execute tasks in a job.
Stages Organizes jobs within a pipeline.
Task groups Encapsulates a sequence of tasks into a single reusable task. If using YAML, see templates.
Tasks Defines the building blocks that make up a pipeline.
Triggers Defines the event that causes a pipeline to run.
Variables Represents a value to be replaced by data to pass to the pipeline.
Variable groups Use to store values that you want to control and make available across multiple pipelines.

Next steps