参考：

- Create your first pipeline - Azure Pipelines | Microsoft Learn

Start:

- What is Azure Pipelines? - Azure Pipelines | Microsoft Learn

- Customize your pipeline - Azure Pipelines | Microsoft Learn

Basic:

- Azure Pipelines New User Guide - Key concepts - Azure Pipelines | Microsoft Learn

Azure Pipelines is the part of Azure DevOps that automatically builds, tests, and deploys code projects. Azure Pipelines combines continuous integration, continuous testing, and continuous delivery to build, test, and deliver your code to any destination. Azure Pipelines supports all major languages and project types.

Understand the azure-pipelines.yml file

点击左侧菜单栏里 “Pipelines”，然后点击我们要查看的 Tiger0817.java_test，如下图，在右上角有 Edit，可以打开 yml 文件

Pool 可以选择：

1.

2. 

3

You can build and test your project on multiple platforms

To build a project using different versions of that language

另外：

完整版

- use trigger: to cause a pipeline to run whenever you push an update to a branch / 如果向branch推送更新时候，那么pipeline被触发运行

- 默认选择 default branch (which is usually main). 也可以选择特定 Branch (You can set up triggers for specific branches

- For pull request validation: 用 pr: 代替 triger:

You can specify the full name of the branch 可以输入完整Branch的名称 (for example, main), or a prefix-matching wildcard (for example, releases/*) (或前缀匹配通配符（例如releases/*))

Processing of new run requests (Sometimes you'll want to prevent new runs from starting on your pipeline)

- Enabled, by default, the processing of new run requests is Enabled. This setting allows standard processing of all trigger types, including manual runs.

- Paused, allow run requests to be processed, but those requests are queued without actually starting. When new request processing is enabled, run processing resumes starting with the first request in the queue.

- Disabled, prevent users from starting new runs. All triggers are also disabled while this setting is applied. All build policies using a disabled pipeline will show "Unable to queue Build" message next to the build policy in the PR overview window and the status of the build policy will be broken.

Key concepts for new Azure Pipelines users

- Triger:  A trigger tells a pipeline to run.

- Stage:  A pipeline is made up of one or more stages. 

- Environments:  A pipeline can deploy to one or more environments.

- Job:  A stage is a way of organizing jobs in a pipeline and each stage can have one or more jobs.

- Agent:  Each job runs on one agent. A job can also be agentless.

- Step:  Each agent runs a job that contains one or more steps.

- Task / Scrip: A step can be a task or script and is the smallest building block of a pipeline.

- Action:  A task is a prepackaged script that performs an action, such as invoking a REST API or publishing a build artifact.

- Artifact:  An artifact is a collection of files or packages published by a run.

Deployment group 部署组

A deployment group is a set of deployment target machines that have agents installed. A deployment group is just another grouping of agents, like an agent pool. You can set the deployment targets in a pipeline for a job using a deployment group. 部署组是一组安装了代理的部署目标计算机。部署组只是另一组代理，就像代理池一样。您可以使用部署组在工作流中为作业设置部署目标

Environment 环境

An environment is a collection of resources where you deploy your application. One environment can contain one or more virtual machines, containers, web apps, or any service. Pipelines deploy to one or more environments after a build is completed and tests are run. 环境是部署应用程序的资源集合。一个环境可以包含一个或多个虚拟机、容器、web应用程序或任何服务。在构建完成并运行测试后，管道部署到一个或多个环境中

Job

A stage contains one or more jobs. Each job runs on an agent. A job represents an execution boundary of a set of steps. All of the steps run together on the same agent. Jobs are most useful when you want to run a series of steps in different environments. For example, you might want to build two configurations - x86 and x64. In this case, you have one stage and two jobs. One job would be for x86 and the other job would be for x64.

Agentless jobs run in Azure DevOps and Azure DevOps Server without using an agent. A limited number of tasks support agentless jobs.

Stage

A stage is a logical boundary(逻辑边界) in the pipeline. It can be used to mark separation of concerns (for example, Build, QA, and production). Each stage contains one or more jobs. When you define multiple stages in a pipeline, by default, they run one after the other. You can specify the conditions for when a stage runs. 

- When you're thinking about whether you need a stage, ask yourself: 

  - Do separate groups manage different parts of this pipeline? For example, you could have a test manager that manages the jobs that relate to testing and a different manager that manages jobs related to production deployment. In this case, it makes sense to have separate stages for testing and production.

  - Is there a set of approvals that are connected to a specific job or set of jobs? If so, you can use stages to break your jobs into logical groups that require approvals.

  - Are there jobs that need to run a long time? If a job in your pipeline has a long run time, it makes sense to put that job in its own stage.

Step

A step is the smallest building block of a pipeline. For example, a pipeline might consist of build and test steps. A step can either be a script or a task. A task is simply a precreated script offered as a convenience to you. To view the available tasks, see Build and release tasks. For information on creating custom tasks, see Create a custom task.

Task

A task is the building block for defining automation in a pipeline. A task is packaged script or procedure that has been abstracted with a set of inputs.

运行服务器如何建立

You can build your project on

- Microsoft-hosted agents that already include SDKs and tools for various development languages

- Self-hosted agents with specific tools that you need