Skip to main content

Build and Release Pipeline for Your Own Custom VSTS Tasks

Anyone can create their own custom VSTS tasks and put them on the VSTS marketplace. There are tons of these custom tasks and they can be published publicly into the marketplace or privately into your own instance of VSTS. This blog post will demonstrate how to setup a build and release pipeline for these custom tasks (using custom VSTS tasks!).

There are many reasons to create your own tasks on an instance of VSTS. You could be part of a DevOps capability that wants to share common platforms, standardisation, or integrations. Generally though the reasoning is to avoid common steps that are duplicated across different build and release pipelines.

Prerequisites and gotchas

Before actually setting up your own pipeline for custom tasks. You'll need to be able to create them locally first. I find the best tool for this is the tfx-cli that can be found here. It scaffolds your task folder structure and provides a mechanism to publish into VSTS. My personal preference is to write my custom tasks with PowerShell and as such I need to include the VstsTaskSdk in my source. The following structure is the result:


Setting up the pipeline

Install Dependencies

The first thing we need to do is install tfx-cli as a local dependency if we haven't already done so:

npm init
npm install tfx-cli

Generate PAT

After you've done this, you'll need to generate a personal access token from your account. To be extra secure only give this token access to the scope Marketplace (publish) (if you want to push into the VSTS marketplace) and/or Agent Pools (read, manage) (if you want to push into your own VSTS instance).

Take note of this Personal Access Token as we'll need it in a bit.

Create the Build Definition

Go to your instance of VSTS. Create an empty build definition, select your source location, and save the definition:

After you've done this, you'll need to add a custom variable to your definition. Add your pat (which you created previously) as a secret variable:

Security Warning:
As you'll be adding your PAT to this definition, anyone with permission to modify this build definition will be able to execute commands with the permissions that this PAT has on your behalf. 

Make sure that the Build number format in the options tab is empty:

Add Build Number Tokens

In the code for your Custom Task. Open up your task.json file. In version:Patch replace the number with #{BUILD_BUILDNUMBER}# This token will eventually be replaced in the pipeline with the VSTS build number.

Add steps in Build Definition

You will need three steps in the build definition

1. Install TFX on the build agent
Add a npm task with the command install

2. Replace tokens from task.json with the build number
Add a Replace Tokens Task that will automatically replace the build number from VSTS pre-defined environment variables. I like to explicitly define the files where the tokens exist. In our case: task.json

3. Push the Task to VSTS
Create a command line Task with node as the tool and the following arguments:

.\node_modules\tfx-cli\ build tasks upload --task-path ./ --service-url https://{YOUR_INSTANCE} --token $(pat)


The above is a very simple example on how we can create a pipeline for our custom tasks. However, there are various things that can be done to minimise chances of error and noise. These things include:
  • Creating separate pipelines for build (npm install and update build number) and release (Push)
  • As part of building including the PowerShell Task SDK.
The above improvements and others can be made depending on your specific team organisation and preferences. I'll leave that up to you! Thanks for reading.


Popular posts from this blog

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

Context and agile practices

At times we have competing responsibilities - ship code or don't ship it because of a small edge case bug; put pressure on our team or make the business happy; coach our friends or write code.

This is a normal part of our everyday professional lives, and it's important to strike a balance that will help us in the future, but also deliver in the short-term.