In this article

Use the visual designer

In this article

Azure Pipelines | TFS 2018 | TFS 2017

Note

In Microsoft Team Foundation Server (TFS) 2018 and previous versions,
build and release pipelines are called definitions,
service connections are called service endpoints,
stages are called environments,
and jobs are called phases.

Note

This guidance applies to TFS version 2017.3 and newer.

Tip

For build pipelines, we recommend that you use YAML instead of the visual designer that is explained below. YAML allows you to use the same branching and code review practices for your pipeline as you would for your application code. See Create your first pipeline.

We'll show you how to use the visual designer in Azure Pipelines to create a build and release that prints "Hello world". If you plan to use a YAML file instead of the visual designer, then see Create your first pipeline instead.

We'll show you how to use TFS to create a build and a release that prints "Hello world".

Prerequisites

You need an Azure DevOps organization. If you don't have one, you can 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 Azure DevOps organization is different from your GitHub organization. Give them the same name if you want alignment between them.)

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

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

Start with an Empty job.

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

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.

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

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

Select Save & queue, and then select Save.

Select Build and Release, and then choose Builds.

Create a new pipeline.

Start with an empty pipeline

Select Pipeline and specify whatever Name you want to use. For the Agent pool, select Default.

On the left side, select + Add Task to add a task to the job, and then on the right side select the Utility category, select the PowerShell task, and then choose Add.

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

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

Select Save & queue, and then select Save.

Select Azure Pipelines, and then the Builds tab.

Create a new pipeline.

Start with an empty pipeline.

Select Pipeline and specify whatever Name you want to use.

On the Options tab, select Default for the Agent pool, or select whichever pool you want to use that has Windows build agents.

On the Tasks tab, make sure that Get sources is set with the Repository and Branch in which you created the script.

On the left side select Add Task, and then on the right side select the Utility category, select the PowerShell task, and then select Add.

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

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

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.

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

Artifact Name: Enter drop.

Artifact Type: Select Server.

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)

Select the Triggers tab.

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.

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.

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.

Go to the build summary.

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

You can view a summary of all the builds or drill into the logs for each build at any time by navigating to the Builds tab in Azure Pipelines. For each build, you can also view a list of commits that were built and the work items associated with each commit. You can also run tests in each build and analyze the test failures.

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

On the dialog box, select the Queue button.

This queues a new build on the agent. 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.

Go to the build summary.

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

You can view a summary of all the builds or drill into the logs for each build at any time by navigating to the Builds tab in Build and Release. For each build, you can also view a list of commits that were built and the work items associated with each commit. You can also run tests in each build and analyze the test failures.

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.

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 just 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.

Go to the Pipelines tab, and then select Releases.

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.

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.

Define the trigger settings and artifact source for the release and then select Queue.

Open the release that you just created.

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

Create a new release.

Open the release that you just created.

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.

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

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

Next steps

You've just learned the basics of using the visual designer to create and run 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.