Updated: 5th Aug 2016 added notes in PublisherID
I have been developing a few VSTS/TFS build related extensions and have published a few in the VSTS marketplace. This has all been a somewhat manual process, a mixture of Gulp and PowerShell has helped a bit, but I decided it was time to try to do a more formal approach. To do this I have used Jesse Houwing’s VSTS Extension Tasks.
Even with this set of tasks I am not sure what I have is ‘best practice’, but it does work. The doubt is due to the way the marketplace handles revisions and preview flags. What I have works for me, but ‘your mileage may differ’
The core of my workflow is that I am building the VSIX package twice, once as a private package and the other as a public one. They both contain the same code and have the same version number, they differ in only visibility flags
I am not using a the preview flag options at all. I have found they do not really help me. My workflow is to build the private package, upload it and test it by sharing it with a test VSTS instance. if all is good publish the matched public package on the marketplace. In this model there is no need to use a preview, it just adds complexity I don’t need.
This may not be true for everyone.
The build’s job is to take the code, set the version number and package it into multiple VSIX package.
- First I have the vNext build get my source from my GitHub repo.
- I add two build variables $(Major) and $(Minor) that I use to manually manage my version number
- I set my build number format to $(Major).$(Minor).$(rev:r), so the final .number is incremented until I choose to increment the major or minor version.
- I then use one of Jesse’s tasks to package the extension multiple times using the extension tag model parameter. Each different package step uses different Visibility settings (circled in red). I also set the version, using the override options, to the $(Build.BuildNumber) (circled in green)
- [Updated Aug 2016] Set the PublisherID and ExtensionID on the tasks, using a pair of build variables is a good idea here to avoid entering strings twice. It is important thay the PublisherID is entered with the correct case - it is case sensitive within the marketplace. Strange things happend of the PublisherID in a VSIX package differ from the one registered on the marketplace
- As I am using the VSTS hosted build agent I also need to make sure I check the install Tfx-cli in the global setting section
- I then add a second identical publish task, but this time there is no tag set and the visibility is set to public.
- Finally I use a ‘publish build artifacts’ task to copy the VSIX packages to a drop location
So now I have multiple VSIX packages I can use the same family of tasks to create a release pipeline.
I create a new release linked to be a Continuous Deployment of the previously created build and set its release name format to Release-$(Build.BuildNumber)
My first environment uses three tasks, all using the option - to work from a VSIX package.
Note In all cases I am using the VSIX path in the format $(System.DefaultWorkingDirectory)/GenerateReleaseNotes.Master/vsix/<package name>-<tag>-$(Build.BuildNumber).vsix. I am including the build number variable in the path as I chose to put all the packages in a single folder, so path wildcards are not an option as the task would not know which package to use unless I alter my build to put one VSIX package per folder.
My tasks for the first environment are
- Publish VSTS Extension – using my private package so it is added as a private package to the marketplace
- Share VSTS Extension – to my test VSTS account
- Install VSTS Extension – to my test VSTS account
For details in the usage of these tasks and setting up the link to the VSTS Marketplace see Jesse’s wiki
If I only intend a extension to ever be private this is enough. However I want to make mine public so I add a second environment that has manual pre-approval (so I have to confirm the public release)
This environment only needs single task
- Publish VSTS Extension – using my public package so it is added as a public package to the marketplace
I can of course add other tasks to this environment maybe send a Tweet or email to publicise the new version’s release
So now I have a formal way to release my extensions. The dual packaging model means I can publish two different versions at the same time one privately and the other public
It is now just a case of moving all my extensions over to the new model.
Though I am still interested to hear what other people view are? Does this seem a reasonable process flow?