VSTS task/extension upgrade explained

Hello,

There is quite good documentation on Microsoft web sites on how to build custom tasks and custom extensions but things become a little more complicated when it comes to upgrading existing tasks and/or extensions. Since I ended up reverse engineering extensions built by big third parties (by downloading them), I thought it was well worth a blog post to prevent you having the same pain.

That said, you have to distinguish the tasks & extensions. For a private use, one can perfectly work only with tasks. Extensions are a way to distribute one or more tasks from the market place, either for a private share, either for public share. I will only consider the latter.

Fixing a bug

If you want to fix a bug of an existing task, you can simply upgrade the patching or minor version number and upgrade the extension number in the manifest.

"version": {
"Major": "1",
"Minor": "0",
"Patch": "1"
}

Updating the extension in the Management Portal (I’ll come to this later) will automatically make the build agents of accounts consuming the extension, picking up the last version of the task.

Publishing a major version of a task

If the change is bigger than merely a bug fix and if you want to have task versions side by side to avoid breaking anything or to propose multiple versions of a same task such as:

taskupdate

you’ll need to work a little more. In that case, you can duplicate your existing task but end up with a folder structure like this:

my task
–v1
—-v1 artifacts
–v2
—-v2 artifcats
–…

The task identifier must remain the same, the name may be left unchanged or be changed and the major versions must be different. In the extension manifest, the contribution should refer to the root folder of the task and its identifier like this:

"contributions": [
    {
      "id": "ca1755b2-751f-45e3-9bad-89a5c08d457d",
      "type": "ms.vss-distributed-task.task",
      "targets": [
        "ms.vss-distributed-task.tasks"
      ],
      "properties": {
        "name": "rootfoldername"
      }
    }
  ]

Deleting a task or a version

I wouldn’t recommend you trying this but it seems to have no effect on accounts having already your extension installed, and this, to avoid any disruption of service I guess. However, beware that removing an extension from the marketplace seems to be one step too far as existing account’s build/release definitions will be broken if using tasks from your extension.

In case of a mere task/version deletion, new accounts will only see the remaining tasks and/or versions while existing accounts would only get a fresh copy by uninstalling and reinstalling completely the extension which is unlikely to happen. It could be handy at tenant level to have an upgrade version as well to opt-in explicitly and have a better control over what the supplier is doing. Today, the only two options are “Disable” and “Uninstall”.

Updating the extension itself

The only way to push changes to existing and new accounts is to publish a new version of the extension itself. This can be easily done by updating the extension manifest manually and by calling tfx extension create, or simply by calling tfx extension create –rev-version which will create the extension package and change the manifest in order to increment the version number. Once the package is produced, you can simply use the update menu option:

vstsextupdate

Happy VSTS.

 

Advertisements

About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in vsts and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s