I'm happy to announce that version 1.1.75 of the Azure DevOps Extension Tasks (formerly CI/CD Tools for VSTS Extension) is rolling out to the Visual Studio Marketplace. The last few releases have added a couple of significant features that I'd like to quickly highlight in this post.

Support for extensions with more than one major task version of the same task.

• Added: Support for extension that contain multiple versions of the same build tasks.
• Fixed: race condition causing build task versions to not always be updated prior to packaging.

It's possible to pack multiple versions of a single build task in the same extension. This enables the following scenarios:

• Ship an older version of your tasks and allow users to upgrade at their leisure.
• Ship a preview version of your tasks and allow users to provide early feedback.
• Ship Long Time Support (LTS) versions of your build tasks.

Multi-Version-Tasks have the following requirements:

• Task ID must be the same across versions.
• Task Name must be the same across versions.
• Each task must have a different Major version.
• Both tasks are stored in a subfolder under the contributions main folder.

The Azure DevOps Extension Tasks will now correctly update the version when you use the following settings:

In your sources ensure that the task.json for each task has the appropriate major (and optionally minor) version set.

vss-extension.json { "version": 3.2.1 }
- MultiVersionBuildTask
  - MultiVersionBuildTaskV1
    - task.json { "version": 1.0.0 }
  - MultiVersionBuildTaskV2
    - task.json { "version": 2.0.0 }
  - MultiVersionBuildTaskV3
    - task.json { "version": 3.0.0, "preview": true }

- SingleVersionBuildTask
  - task.json { "version": 1.0.0 }

Note: Remember, each version requires its own set of powershell/node modules.

It's possible to mix multi-version tasks and single version tasks in the same extension, however, they must follow the same Version Override Scheme.

Support for generating Task IDs based on the Publisher, Extension ID and Task Name.

• Added: Ability to generate consistent GUIDs for Build tasks during build.

The recommend practice for build task development is to have a secondary Azure DevOps Organization to test your non-production versions of the tasks on. In my case that means I have:

• jessehouwing.visualstudio.com - My primary Azure DevOps Organization that contrains all the builds, releases and source repositories for my projects
• jessehouwing-dev.visualstudio.com - My test environment for Azure DevOps extension that are built, released and shared from the primary account.

The biggest advantage of this setup is that I can re-use the same Task ID and Task Names in my dev/test packages as I use in my production packages. The only thing I override between dev and production is the Extension ID and he Visibility:

Multiple private extensions can share the same Task ID and Task Names.

However, if you need to publish and activate more than one version of the same Extension in a single Azure DevOps Organization, you'll need to ensure that each extension is using unique GUIDs for the Task ID, or things will break.

This gets us into trouble with GUIDs. They are generally globally unique, so while it's easy to come up with random values every build, that will break any existing Build or Release that references these tasks.

Fortunately, there is a UUID standard (v5) which allows you to feed in the parameters which are used to generate the UUID. The Azure DevOps Extension Tasks can now use this standard to derive the Task ID from the following inputs:

• Publisher ID (taken from vss-extension.json, unless overridden)
• Extension ID (taken from vss-extension.json, unless overridden)
• Extension Tag (appended to Extension ID when supplied)
• Task Name (taken from task.json)

This option is enabled through the "Override task id" option:

Support for marketplace validation checks

• Added: Release gate task to wait for marketplace verification.
• Added: Agent phase task to wait for marketplace verification.
• Added: Support for --no-wait-validation.

The Visual Studio Marketplace is now actively scanning extensions for unwanted contents (viruses mostly). This validation can be instant, but it sometimes takes longer. In that case we will receive an error upon trying to publish the extension, which will fail your build/release. Or at least, that was the case.

When this feature was introduced in the Marketplace, tfx was also updated to support the --no-wait-validation flag, which would not wait for validation to complete once the extension was uploaded to the marketplace. Great, so your pipeline won't break when validation takes a while, but this also means that the build will succeed, even if the extension doesn't pass validation:

We've added two new tasks to help handle this last case:

• The Is Valid Extension task which runs on the agent - This version is the easiest to use, just drop it into the build or release pipeline at the end and let it poll the marketplace until validation either succeeds or fails. When validation fails the task will fail immediately. The downside is that this task is running on the agent and thus consumes build minutes and allocates a concurrent pipeline.

• The Is Valid Extension task which runs on the Server - This version requires you to link a Release Pipeline to your build and to configure release gates. It runs on the server and doesn't consume build minutes nor a concurrent pipeline. You may not have access to all the variable in the server context to run this task. When validation fails the task will not fail until the timeout expires.

During development of the Release Gate task, we've provided extensive feedback to the team building Release Gates. We'll address some of the downsides of using the Release Gate task in a future release as soon as the required features become available.

We're also working with the team working on tfx to see if some of the features in these tasks can be merged into tfx. Please vote/comment on these issues if you'd like them to be implemented:

• extend tfx extension publish to allow overriding baseUri tfs-cli#263
• Extend rev-version to also update task.json build patch numbers tfs-cli#262
• Extend local validation to detect issues with Build tasks tfs-cli#261

Are you using the Azure DevOps Extension Tasks? Are there features you'd like to see? Are you using another technique? What benefits do you get from that? I'd love to hear your thoughts in the comments below.