| title | description | ms.prod | ms.technology | ms.topic | ms.assetid | ms.manager | ms.author | author | ms.date | monikerRange |
|---|---|---|---|---|---|---|---|---|---|---|
Create your first build and release | VSTS |
CI/CD novice? Create an automated build and release pipeline in VSTS and TFS |
devops |
devops-cicd |
quickstart |
038A5329-1B8F-46D9-A0C3-DA3FCFA43996 |
douge |
alewis |
andyjlewis |
05/11/2018 |
>= tfs-2017 |
::: moniker range="vsts"
We'll show you how to use VSTS pipelines to create a build that prints "Hello world" and then automatically creates a release that does the same. By the time you finish here, you'll see an end-to-end process run every time you push new code into your team project. You'll also become familiar with all the basic concepts of VSTS pipelines.
::: moniker-end
::: moniker range="< vsts"
We'll show you how to use TFS to create a build that prints "Hello world" and then automatically creates a release that does the same. By the time you finish here, you'll see an end-to-end process run every time you push new code into your team project. You'll also become familiar with all the basic concepts of build and release in TFS.
::: moniker-end
::: moniker range="vsts"
[!INCLUDE include]
::: moniker-end
::: moniker range="< vsts"
::: moniker-end
Create a PowerShell script that prints Hello world.
-
Go to the Code hub.
-
Add a file.
::: moniker range="vsts"
::: moniker-end
::: moniker range="tfs-2018"
::: moniker-end
::: moniker range="tfs-2017"
::: moniker-end
- In the dialog box name your new file.
HelloWorld.ps1
- Copy and paste this script.
Write-Host "Hello world"- 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 a VSTS 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 VSTS CI builds. Learn more.
Create a build definition that prints "Hello world."
::: moniker range="vsts"
-
Select the Build and Release hub in your VSTS project, and then choose Builds.
-
Create a new definition.
-
Make sure that the source, team project, repository, and default branch match the location in which you created the script.
-
Start with an empty process
-
Select Process and specify whatever Name you want to use. For the Agent queue, select Hosted VS2017.
-
On the left side, select the plus sign ( + ) for Phase 1 to add a task to the phase, 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.
::: moniker-end
::: moniker range="tfs-2018"
-
Select the Build and Release hub in your VSTS project, and then choose Builds.
-
Create a new definition.
-
Start with an empty process
-
Select Process and specify whatever Name you want to use. For the Agent queue, select Default.
-
On the left side, select + Add Task to add a task to the phase, 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.
::: moniker-end
::: moniker range="tfs-2017"
- Select the Build and Release hub in your VSTS project, and then the Builds tab.
- Create a new definition.
-
Start with an empty process.
-
Select Process and specify whatever Name you want to use.
-
On the Options tab, select Default for the Agent queue, or select whichever queue 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.
::: moniker-end
A build definition is the entity through which you define your automated build process. In the build definition, 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 definition.
A typical build produces an artifact that can then be deployed to various environments in a release. Here to demonstrate the capability in a simple way, we'll simply publish the script as the artifact.
::: moniker range="vsts"
-
On the Tasks tab, select the plus sign ( + ) for Phase 1 to add a task to the phase.
-
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
dropArtifact publish location: Visual Studio Team Services/TFS.
::: moniker-end
::: moniker range=">= tfs-2017 < vsts"
-
On the Tasks tab, select Add Task.
-
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
drop
Artifact Type: Server.
::: moniker-end
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 Team Build.
-
Select the Triggers tab.
-
Enable Continuous integration.
A continuous integration trigger on a build definition 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 a build manually and test your build definition.
::: moniker range=">= tfs-2018 <= vsts"
-
Select Save & queue, and then select Save & queue.
-
On the dialog box select Save & queue once more.
This queues a new build on the Microsoft-hosted agent.
-
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.
-
Go to the build summary.
-
On the Artifacts tab of the build notice that the script is published as an artifact.
::: moniker-end
::: moniker range="tfs-2017"
-
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.
::: moniker-end
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 the Build and Release hub. 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.
We'll pass some build variables to the script to make our process a bit more interesting. Then we'll commit a change to a script and watch the CI process run automatically to validate the change.
-
Edit your build definition.
-
On the Tasks tab, select the PowerShell script task.
-
Add these arguments.
::: moniker range="vsts"
::: moniker-end
::: moniker range=">= tfs-2017 < vsts"
::: moniker-end
Arguments
-greeter "$(Build.RequestedFor)" -trigger "$(Build.Reason)"
-
Save the build definition.
-
Go to the Code hub, Files tab.
-
Select the HelloWorld.ps1 file, and then Edit the file.
-
Change the script as follows:
Param(
[string]$greeter,
[string]$trigger
)
Write-Host "Hello world" from $greeter
Write-Host Trigger: $trigger-
Commit (save) the script.
-
Go to the Build and Release hub, and notice that a build is automatically triggered by the change that you committed.
-
Select the new build that was created and view its log.
-
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 just created a build definition 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 definitions. Or, if you prefer, you can skip ahead to create a build pipeline for your app.
Define the process for running the script in two environments.
::: moniker range=">= tfs-2018 <= vsts"
-
Go to the Build and Release tab, and then select Releases.
-
Select the action to create a New definition. If a release definition is already created, select the plus sign ( + ) and then select Create release definition.
-
Select the action to start with an empty process.
-
Name the environment QA.
-
In the Artifacts panel, select + Add and specify a Source (Build definition). Select Add.
-
Select the Lightning bolt to trigger continuous deployment and then enable the Continuous deployment trigger on the right.
-
Select the Tasks tab and select your QA environment.
-
Select the plus sign ( + ) for the phase to add a task to the phase.
-
On the Add tasks dialog box, select Utility, locate the PowerShell task, and then select its Add button.
-
On the left side select your new PowerShell script task.
-
For the Script Path argument, select the ... button to browse your artifacts and select the script you created.
-
Add these Arguments:
-greeter "$(Release.RequestedFor)" -trigger "$(Build.DefinitionName)" -
On the Pipeline tab, select the QA environment and select Clone.
-
Rename the cloned environment Production.
-
Rename the release definition Hello world.
-
Save the release definition.
::: moniker-end
::: moniker range="tfs-2017"
-
Go to the Build and Release hub, and then to the Releases tab.
-
Select the action to create a New definition.
-
On the dialog box, select the Empty template and select Next.
-
Make sure that your Hello world build definition that you created above is selected. Select Continuous deployment, and then select Create.
-
Select Add tasks in the environment.
-
On the Task catalog dialog box, select Utility, locate the PowerShell task, and then select its Add button. Select the Close button.
-
For the Script Path argument, select the ... button to browse your artifacts and select the script you created.
-
Add these Arguments:
-greeter "$(Release.RequestedFor)" -trigger "$(Build.DefinitionName)"
- Rename the environment QA.
- Clone the QA environment.
Leave Automatically approve and Deploy automatically... selected, and select Create.
-
Rename the new environment Production.
-
Rename the release definition Hello world.
- Save the release definition.
::: moniker-end
A release definition is a collection of environments to which the application build artifacts are deployed. It also defines the actual deployment process for each environment, as well as how the artifacts are promoted from one environment 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 definition.
Run the script in each environment.
::: moniker range="vsts"
- Create a new release.
-
Define the trigger settings and artifact source for the release and then select Create.
-
Open the release that you just created.
- View the logs to get real-time data about the release.
::: moniker-end
::: moniker range="tfs-2018"
- Create a new release.
-
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.
::: moniker-end
::: moniker range="tfs-2017"
- Create a new release.
- Open the release that you just created.
- View the logs to get real-time data about the release.
::: moniker-end
You can track the progress of each release to see if it has been deployed to all the environments. 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 process.
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 environment.
- 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 $greeter
Write-Host Trigger: $trigger
Write-Host "Now that you've got CI/CD, you can automatically deploy your app every time your team checks in code."-
Commit (save) the script.
-
Select the Builds tab to see the build queued and run.
-
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 environment, and then in the Production environment.
::: moniker range=">= tfs-2018 <= vsts"
::: moniker-end
::: moniker range="tfs-2017"
::: moniker-end
In many cases, you probably would want to edit the release process so that the production deployment happens only after some testing and approvals are in place. See Approvals and gates overview.
We hope this tutorial gave you an understanding of the basic concepts of Team Build and Release Management. To get started building and deploying an app, we suggest you proceed next to one of these topics:
You've just learned the basics of using the designer to create and run a VSTS build and release process. Now you're ready to configure your build definition for the programming language you're using. Go ahead and create a new build pipeline, and this time, use one of the following templates.
| Language | Template to use |
|---|---|
| .NET | ASP.NET |
| .NET Core | ASP.NET Core |
| C++ | .NET Desktop |
| Go | Go |
| Java | Gradle |
| JavaScript | NodeJS with Gulp (Grunt is also an option) |
| Xcode | Xcode |
What is Continuous Integration?
We've used a Git repository in VSTS to keep things focused on CI/CD for this tutorial.
When you're ready to get going with CI/CD for your app, you can use the version control system of your choice:
-
Clients
-
Services
-
Git service providers such as GitHub and Bitbucket
-
Subversion
If your definition has a pattern that you want to replicate in other definitions, clone it, export it, or save it as a template.
After you clone a definition, you can make changes and then save it.
After you export a definition, you can import it from the All Definitions tab.
After you create a template, your team members can use it to follow the pattern in new definitions.
Tip
If you're using the New Build Editor, then your custom templates are shown at the bottom of the list.
If you're editing a build definition and you want to test some changes that are not yet ready for production, you can save it as a draft.
You can edit and test your draft as needed.
When you're ready you can publish the draft to merge the changes into your build definition.
Or, if you decide to discard the draft, you can delete it from the All Definition tab shown above.
You can queue builds automatically or manually.
When you manually queue a build, you can, for a single run of the build:
-
Specify the queue into which the build goes.
-
Add and modify some variables.
-
Add demands.
-
In a Git repository
- In a TFVC repository
-
Run a private build of a shelveset. (You can use this option on either a Microsoft-hosted agent or a self-hosted agent.)
To learn more about build definition settings, see:
REST API Reference: Create a build definition
Note
You can also manage builds and build definitions from the command line or scripts using the VSTS CLI.