Back to Top

TFS – Importing Artifacts from VSTS

BuildMaster is an application release automation tool. In this tutorial, we will demonstrate how to utilize the TFS extension by creating a build in VSTS, creating a Release Package from that build, and deploying it all the way through production.


Operations

Once the VSTS extension (Visual Studio Team Services and TFS) is installed on BuildMaster, additional built-in operations can be called in a deployment plan, such as:

  • Import Artifact from TFS or VSTS - Downloads an artifact from the specified TFS Server or VSTS and save it to the artifact library
  • Queue VSTS Build - Queue a build in TFS or VSTS optionally waiting for its completion
  • Get Latest - Get latest version of code from TFS Server

Specific Issue Tracking operations added include:

  • Create TFS Work Item - Creates a work item in TFS
  • Transition TFS Work Item - Transitions work items in TFS from one status to another
  • Generate Release Notes - Generates an HTML file containing the BuildMaster release notes and/or issues from TFS
  • Halt promotions - Halts a promotion of a release when a TFS work item of a specific status exists

VSTS Setup

NOTE: As of September 2018, VSTS is now called "Azure DevOps"

This tutorial will work for projects on TFS (tested with TFS 2015 through TFS 2018) as well, but the screenshots will be focused on completing the task through VSTS.

We'll be using the build-related features of VSTS to work with a simple project called Accounts. In the Accounts project, we must configure a build definition (named Basic) that creates an artifact (named Websites). First, we will create a simple project in VSTS called Accounts. After creating the project, create a new build within the project. You can do this by clicking on the Build and Release tab and then clicking Builds, to bring up the builds page. The next step is to click the +New button in order to create a new build.

Next, we will make sure VSTS Git is selected and click Continue. On the next page we will select our template, for this tutorial we will go with the .NET Desktop template and hit Apply.

The next page will be auto filled with information, but let's change the build name to Basic and leave the rest of the information as the default input.

After this, select the Publish Artifact: Drop feature. Make sure to change the Display Name to Publish Artifacts: Websites, as well as the Artifact Name to Websites. When finished, click the Save & Queue drop down menu, but just select Save.

At this point we are finished with the VSTS setup and ready to move on to the BuildMaster procedure.

 

BuildMaster Steps

 

Step 1: Install and configure the TFS Extension

Go to the Admin page by clicking the gear symbol in the upper left-hand corner and then click the on Extensions.

On this page, scroll down and look for the TFS extension install. Click this and BuildMaster will automatically restart and you should see TFS under the list of installed extensions.

Back on the Admin page, click Resource Credentials, and then click the Create Credential button. A window will pop up, asking you to select a credential type, select Team Foundation Server.

In BuildMaster, Resource Credentials allow you to connect to different VSTS accounts and TFS instances. We’ll configure a profile with VSTS credentials.

Note: For both TFS and VSTS, you will need to create a Personal Access Token; your regular password will not work.

 

Step 2: Create an Application in BuildMaster

Click on Applications, then click the Create Application button. This will bring up a window, where you will set the name to Accounts. When creating the application, the Integration, Testing, and Production environments will be added by default as the initial pipeline. When finished, click Create.

 

Step 3: Create an Import Plan

We first need to import an artifact from VSTS. For that we'll create a Plan that will queue a build in VSTS from BuildMaster and import the artifact from the queued build.

Create a new plan and call it Import Build.

Start with a General Block to describe what will be happening in this plan. In the short description add Queue and Import Build as shown below, then save.

Inside the General Block we just created, add a Set Release Variable operation, where you can add a build variable name and value. For this project we will just be setting the value to 0 in order to initialize the variable. The subsequent operations in this plan will replace this value.

Alternatively, if your repository has a release or package that you would like to use, these can also be specified in this operation:

Next, we will add a Queue VSTS Build to the General Block. After a valid credential is set, BuildMaster will create drop-down choices for the Team project name and Build definition. We will also add the build number variable at the bottom.

Next, we will add an Import Artifact from VSTS to the General Block. We'll again set the resource credential as well as the Artifact name, the Team project, the Build definition and the build number variable. We'll use latest to import the build we just queued.

This is what the plan should look like in Visual Mode if done correctly:

And here is the view in Text Mode (Otter Script):

 

Step 4: Edit Application Pipeline and Set Import Plan

When we created the application, a simple pipeline was also created which we can now edit.

Go to Accounts and click the Pipelines tab, then click Accounts.

Next, we need to import the VSTS artifact. We'll create a new Stage for that, so click the Add Stage button.

Set Name to Import, set Pipeline position to 0 - Integration, then click Save Stage.

By setting the Pipeline position to 0, the stage is created as the first stage in the pipeline, since we need to import a build before we can move it through our pipeline.

Next, we need to set the import stage with our import plan. Click add target on the import stage and set the plan to Global::Import Build.

 

Step 5: Edit the Deployment Plan

As noted above, we already have a plan assigned to our pipeline stages called Deploy Accounts; we'll now edit that plan.

Go to the Plans tab, then click on Deploy Accounts.

BuildMaster has automatically created a simple deployment plan by default. The plan doesn't do much, but we can edit it so that it will deploy the artifact that we'll import through the pipeline.

Edit the General Block at the top with a short description of what the plan will do and set a server for the plan to be run on. Note that you can also target environments and servers to execute operations on from the pipeline stage, but for this tutorial, we'll just set it here.

The two default actions in the plan can be deleted and we will replace them by dragging a Deploy Artifact operation into the edited General Block. Set the Artifact name to Websites, and the Target directory to C:\Websites\$EnvironmentName\Accounts. Using $EnvironmentName will create a new folder for each environment that the application is deployed to and demonstrates one way to generalize a deployment plan for use in multiple environments.

 

Step 6: Creating a Release and Deploying

We can now create a Release that deploys the build artifact we created with a release package. The release number can be anything, but defaults to 0.0.0.

Click on the Releases tab, then click Create Release.

Once the release is created, you can now create a package, which will use the import plan we defined.

Click the Create Package button, then click Create Package.

BuildMaster will now run the Import Plan we created to queue a VSTS Build and then Import the artifact to BuildMaster. We can see that there has been an artifact created called Websites.

You can now run the artifact through the rest of the pipeline simply by clicking Deploy in each successive stage. Of course, you can also configure gates, listeners, and permissions to ensure that a proper process is followed.

You can further verify that the deployment was successful by checking the drive used when setting up the deployment plan. There will be three folders under /Websites, one for Integration, Testing, and Production, each containing the deployed files.