Create your first pipeline - Azure Pipelines (2024)

This is a step-by-step guide to using Azure Pipelines to build a sample application from a Git repository. This guide uses YAML pipelines configured with the YAML pipeline editor. If you'd like to use Classic pipelines instead, see Define your Classic pipeline. For guidance on using TFVC, see Build TFVC repositories.

Prerequisites - Azure DevOps

Make sure you have the following items:

• A GitHub account where you can create a repository. Create one for free.

• An Azure DevOps organization. Create one for free.If your team already has one, then make sure you're an administrator of the Azure DevOps project that you want to use.

• An ability to run pipelines on Microsoft-hosted agents. To use Microsoft-hosted agents, your Azure DevOps organization must have access to Microsoft-hosted parallel jobs. You can either purchase a parallel job or you can request a free grant.

Create your first pipeline

https://github.com/MicrosoftDocs/pipelines-java

View and manage your pipelines

You can view and manage your pipelines by choosing Pipelines from the left-hand menu to go to the pipelines landing page.

From the pipelines landing page you can view pipelines and pipeline runs, create and import pipelines, manage security, and drill down into pipeline and run details.

Choose Recent to view recently run pipelines (the default view), or choose All to view all pipelines.

Select a pipeline to manage that pipeline and view the runs. Select the build number for the last run to view the results of that build, select the branch name to view the branch for that run, or select the context menu to run the pipeline and perform other management actions.

Select Runs to view all pipeline runs. You can optionally filter the displayed runs.

Select a pipeline run to view information about that run.

You can choose to Retain or Delete a run from the context menu. For more information on run retention, see Build and release retention policies.

View pipeline details

The details page for a pipeline allows you to view and manage that pipeline.

Choose Edit to edit your pipeline. For more information, see YAML pipeline editor. You can also edit your pipeline by modifying the azure-pipelines.yml file directly in the repository that hosts the pipeline.

View pipeline run details

From the pipeline run summary you can view the status of your run, both while it is running and when it is complete.

From the summary pane you can view job and stage details, download artifacts, and navigate to linked commits, test results, and work items.

Jobs and stages

The jobs pane displays an overview of the status of your stages and jobs. This pane may have multiple tabs depending on whether your pipeline has stages and jobs, or just jobs. In this example, the pipeline has two stages named Build and Deploy. You can drill down into the pipeline steps by choosing the job from either the Stages or Jobs pane.

Choose a job to see the steps for that job.

From the steps view, you can review the status and details of each step. From the More actions you can toggle timestamps or view a raw log of all steps in the pipeline.

Cancel and re-run a pipeline

If the pipeline is running, you can cancel it by choosing Cancel. If the run has completed, you can re-run the pipeline by choosing Run new.

Pipeline run more actions menu

From the More actions menu you can download logs, add tags, edit the pipeline, delete the run, and configure retention for the run.

Add a status badge to your repository

Many developers like to show that they're keeping their code quality high by displaying a status badge in their repo.

To copy the status badge to your clipboard:

1. In Azure Pipelines, go to the Pipelines page to view the list of pipelines. Select the pipeline you created in the previous section.

2. Select , and then select Status badge.

3. Select Status badge.

4. Copy the sample Markdown from the Sample markdown section.

Now with the badge Markdown in your clipboard, take the following steps in GitHub:

1. Go to the list of files and select Readme.md. Select the pencil icon to edit.

2. Paste the status badge Markdown at the beginning of the file.

3. Commit the change to the main branch.

4. Notice that the status badge appears in the description of your repository.

To configure anonymous access to badges for private projects:

1. Navigate to Project Settings in the bottom left corner of the page

2. Open the Settings tab under Pipelines

3. Toggle the Disable anonymous access to badges slider under General

Because you just changed the Readme.md file in this repository, Azure Pipelines automatically builds your code, according to the configuration in the azure-pipelines.yml file at the root of your repository. Back in Azure Pipelines, observe that a new run appears. Each time you make an edit, Azure Pipelines starts a new run.

Prerequisites

• A self-hosted Windows agent.

Initialize your repository

If you already have a repository in your project, you can skip to the next step: Skip to adding a script to your repo

1. Go to Azure Repos. (The Code hub in the previous navigation)

   

2. If your project is empty, you will be greeted with a screen to help you add code to your repository. Choose the bottom choice to initialize your repo with a readme file:

   

Add a script to your repository

Create a PowerShell script that prints Hello world.

1. Go to Azure Repos.

2. Add a file.

   

3. In the dialog box, name your new file and create it.

   HelloWorld.ps1

4. Copy and paste this script.

   Write-Host "Hello world"

5. Commit (save) the file.

In this tutorial, our focus is on CI/CD, so we're keeping the code part simple. We're working in an Azure Repos Git repository directly in your web browser.

When you're ready to begin building and deploying a real app, you can use a wide range of version control clients and services with Azure Pipelines CI builds. Learn more.

Create a build pipeline

Create a build pipeline that prints "Hello world."

1. Select Azure Pipelines, it should automatically take you to the Builds page.

   

2. Create a new pipeline.

   

   For new Azure DevOps users, this will automatically take you to the YAML pipeline creation experience. To get to the classic editor and complete this guide, you must turn off the preview feature for the New YAML pipeline creation experience:

   

   

3. Make sure that the source, project, repository, and default branch match the location in which you created the script.

4. Start with an Empty job.

5. On the left side, select Pipeline and specify whatever Name you want to use. For the Agent pool, select Hosted VS2017.

6. On the left side, select the plus sign ( + ) to add a task to Job 1. On the right side, select the Utility category, select the PowerShell task from the list, and then choose Add.

   

7. On the left side, select your new PowerShell script task.

8. For the Script Path argument, select the button to browse your repository and select the script you created.

   

9. Select Save & queue, and then select Save.

A build pipeline is the entity through which you define your automated build pipeline. In the build pipeline, you compose a set of tasks, each of which perform a step in your build. The task catalog provides a rich set of tasks for you to get started. You can also add PowerShell or shell scripts to your build pipeline.

Publish an artifact from your build

A typical build produces an artifact that can then be deployed to various stages in a release. Here to demonstrate the capability in a simple way, we'll simply publish the script as the artifact.

1. On the Tasks tab, select the plus sign ( + ) to add a task to Job 1.

2. Select the Utility category, select the Publish Build Artifacts task, and then select Add.

   

   Path to publish: Select the button to browse and select the script you created.

   Artifact name: Enter drop.

   Artifact publish location: Select Azure Artifacts/TFS.

Artifacts are the files that you want your build to produce. Artifacts can be nearly anything your team needs to test or deploy your app. For example, you've got a .DLL and .EXE executable files and .PDB symbols file of a C# or C++ .NET Windows app.

To enable you to produce artifacts, we provide tools such as copying with pattern matching, and a staging directory in which you can gather your artifacts before publishing them. See Artifacts in Azure Pipelines.

Enable continuous integration (CI)

1. Select the Triggers tab.

2. Enable Continuous integration.

A continuous integration trigger on a build pipeline indicates that the system should automatically queue a new build whenever a code change is committed. You can make the trigger more general or more specific, and also schedule your build (for example, on a nightly basis). See Build triggers.

Save and queue the build

Save and queue a build manually and test your build pipeline.

1. Select Save & queue, and then select Save & queue.

2. On the dialog box, select Save & queue once more.

   This queues a new build on the Microsoft-hosted agent.

3. You see a link to the new build on the top of the page.

   

   Choose the link to watch the new build as it happens. Once the agent is allocated, you'll start seeing the live logs of the build. Notice that the PowerShell script is run as part of the build, and that "Hello world" is printed to the console.

   

4. Go to the build summary. On the Artifacts tab of the build, notice that the script is published as an artifact.

   

Add some variables and commit a change to your script

We'll pass some build variables to the script to make our pipeline a bit more interesting. Then we'll commit a change to a script and watch the CI pipeline run automatically to validate the change.

1. Edit your build pipeline.

2. On the Tasks tab, select the PowerShell script task.

3. Add these arguments.

Arguments

-greeter "$(Build.RequestedFor)" -trigger "$(Build.Reason)"

Finally, save the build pipeline.

Next you'll add the arguments to your script.

1. Go to your Files in Azure Repos (the Code hub in the previous navigation and TFS).

2. Select the HelloWorld.ps1 file, and then Edit the file.

3. Change the script as follows:

   Param([string]$greeter,[string]$trigger)Write-Host "Hello world" from $greeterWrite-Host Trigger: $trigger

4. Commit (save) the script.

1. Select the new build that was created and view its log.

2. Notice that the person who changed the code has their name printed in the greeting message. You also see printed that this was a CI build.

We just introduced the concept of build variables in these steps. We printed the value of a variable that is automatically predefined and initialized by the system. You can also define custom variables and use them either in arguments to your tasks, or as environment variables within your scripts. To learn more about variables, see Build variables.

You've got a build pipeline. What's next?

You've created a build pipeline that automatically builds and validates whatever code is checked in by your team. At this point, you can continue to the next section to learn about release pipelines. Or, if you prefer, you can skip ahead to create a build pipeline for your app.

Create a release pipeline

Define the process for running the script in two stages.

1. Go to the Pipelines tab, and then select Releases.

2. Select the action to create a New pipeline. If a release pipeline is already created, select the plus sign ( + ) and then select Create a release pipeline.

3. Select the action to start with an Empty job.

4. Name the stage QA.

5. In the Artifacts panel, select + Add and specify a Source (Build pipeline). Select Add.

6. Select the Lightning bolt to trigger continuous deployment and then enable the Continuous deployment trigger on the right.

   

7. Select the Tasks tab and select your QA stage.

8. Select the plus sign ( + ) for the job to add a task to the job.

9. On the Add tasks dialog box, select Utility, locate the PowerShell task, and then select its Add button.

10. On the left side, select your new PowerShell script task.

11. For the Script Path argument, select the button to browse your artifacts and select the script you created.

12. Add these Arguments:

    -greeter "$(Release.RequestedFor)" -trigger "$(Build.DefinitionName)"

13. On the Pipeline tab, select the QA stage and select Clone.

    

14. Rename the cloned stage Production.

15. Rename the release pipeline Hello world.

    

16. Save the release pipeline.

A release pipeline is a collection of stages to which the application build artifacts are deployed. It also defines the actual deployment pipeline for each stage, as well as how the artifacts are promoted from one stage to another.

Also, notice that we used some variables in our script arguments. In this case, we used release variables instead of the build variables we used for the build pipeline.

Deploy a release

Run the script in each stage.

1. Create a new release.

   

   When Create new release appears, select Create.

2. Open the release that you created.

   

3. View the logs to get real-time data about the release.

   

You can track the progress of each release to see if it has been deployed to all the stages. You can track the commits that are part of each release, the associated work items, and the results of any test runs that you've added to the release pipeline.

Change your code and watch it automatically deploy to production

We'll make one more change to the script. This time it will automatically build and then get deployed all the way to the production stage.

1. Go to the Code hub, Files tab, edit the HelloWorld.ps1 file, and change it as follows:

   Param([string]$greeter,[string]$trigger)Write-Host "Hello world" from $greeterWrite-Host Trigger: $triggerWrite-Host "Now that you've got CI/CD, you can automatically deploy your app every time your team checks in code."

2. Commit (save) the script.

3. Select the Builds tab to see the build queued and run.

4. After the build is completed, select the Releases tab, open the new release, and then go to the Logs.

Your new code automatically is deployed in the QA stage, and then in the Production stage.

In many cases, you probably would want to edit the release pipeline so that the production deployment happensonly after some testing and approvals are in place. See Approvals and gates overview.

You learned how to create your first pipeline in Azure. Now, Learn more about configuring pipelines in the language of your choice:

• .NET Core
• Go
• Java
• Node.js
• Python
• Containers

Or, you can proceed to customize the pipeline you created.

To run your pipeline in a container, see Container jobs.

For details about building GitHub repositories, see Build GitHub repositories.

To learn how to publish your Pipeline Artifacts, see Publish Pipeline Artifacts.

To find out what else you can do in YAML pipelines, see YAML schema reference.

Clean up

If you created any test pipelines, they're easy to delete when you finish with them.

You've learned the basics of creating and running a pipeline.Now you're ready to configure your build pipeline for the programming language you're using.Go ahead and create a new build pipeline, and this time, use one of the following templates.

• Clients

  • Visual Studio Code for Windows, macOS, and Linux
  • Visual Studio with Git for Windows or Visual Studio for Mac
  • Eclipse
  • Xcode
  • IntelliJ
  • Command line

• Services

  • Azure Pipelines
  • Git service providers such as Azure Repos Git, GitHub, and Bitbucket Cloud
  • Subversion

• Clients

  • Visual Studio Code for Windows, macOS, and Linux
  • Visual Studio with Git for Windows or Visual Studio for Mac
  • Visual Studio with TFVC
  • Eclipse
  • Xcode
  • IntelliJ
  • Command line

• Services

  • Azure Pipelines
  • Git service providers such as GitHub and Bitbucket Cloud
  • Subversion

How do I replicate a pipeline?

If your pipeline has a pattern that you want to replicate in other pipelines, clone it, export it, or save it as a template.

After you clone a pipeline, you can make changes and then save it.

After you export a pipeline, you can import it from the All pipelines tab.

After you create a template, your team members can use it to follow the pattern in new pipelines.

How do I work with drafts?

If you're editing a build pipeline and you want to test some changes that are not yet ready for production, you can save it as a draft.

What else can I do when I queue a build?

You can queue builds automatically or manually.

When you manually queue a build, you can, for a single run of the build:

• Specify the pool into which the build goes.

• Add and modify some variables.

• Add demands.

• In a Git repository

  • Build a branch or a tag.

  • Build a commit.

• In a TFVC repository

  • Specify the source version as a label or changeset.

  • Run a private build of a shelveset. (You can use this option on either a Microsoft-hosted agent or a self-hosted agent.)

You can queue builds automatically or manually.

When you manually queue a build, you can, for a single run of the build:

• Specify the pool into which the build goes.

• Add and modify some variables.

• Add demands.

• In a Git repository

  • Build a branch or a tag.

  • Build a commit.

To learn more about pipeline settings, see:

• Getting sources
• Tasks
• Variables
• Triggers
• Retention
• History

How do I programmatically create a build pipeline?

REST API Reference: Create a build pipeline