Updated 3 Feb 2018 - Also see Versioning your ARM templates within a VSTS CI/CD pipeline with Semantic Versioning Azure Resource Templates (ARM) allow your DevOps infrastructure deployments to be treated as ‘content as code’. So infrastructure definitions can be stored in source control. As with any code it is really useful to know which version you have out in production. Now a CI/CD process and its usage logs can help here, but just having a version string stored somewhere accessible on the production systems is always useful....

As part of the continued improvement to my CI/CD process I needed to provide a means so that whenever I test my Generate Release Notes Task, within it’s CI/CD process, new commits and work item associations are made. This is required because the task only picks up new commits and work items since the last successful running of a given build. So if the last release of the task extension was successful then the next set of tests have no associations to go in the release notes, not exactly exercising all the code paths!...

Whist adding a couple of new tasks to my VSTS Manifest Versioning Extension I hit the problem that VSIX package became too big to upload to the Marketplace. The error I saw in my CI/CD VSTS pipeline was``` ##vso[task.logissue type=error;]error: Failed Request: Bad Request(400) - The extension package size ‘23255292 bytes’ exceeds the maximum package size ‘20971520 bytes’ 1. They get a list of files 2. Extract a version number from the build number 3....

In response to requests on the VSTS Marketplace I have added a pair of tasks to added/edit entries in a .JSON format files. The first is for adding a version to a file like a package.json file e.g. { "name": "myapp", "version": "1.0.0", "license": "MIT" } The second is designed for angular environment.ts file e.g. export const environment = { production: true, version: '1.0.0.0' }; But I bet people find other uses, they always do....

Background I have recently been posting on using Azure to host private VSTS build/release agents to avoid agent queue deadlocking issues with more complex release pipelines. One of the areas discussed is reducing cost of running a private agent in Azure by only running the private agent within a limited time range, when you guess it might be needed. I have done this using DevTest Labs Auto Start and Auto Stop features....

In my last post I discussed creating a private VSTS build agent within an Azure DevTest Lab on a VM with no GUI. It was pointed out to me today, by Rik Hepworth, that I had overlooked an obvious alternative way to get the VSTS agent onto the VM i.e. not having to use a series of commands at an RDP connected command prompt. The alternative I missed is to use a DevTest Lab Artifact; in fact there is such an artifact available within the standard set in DevTest Labs....

Updates 28th Nov 2017: Also see this second post Creating a VSTS build agent on an Azure DevLabs Windows Server VM with no GUI - Using Artifacts 30th Nov 2017: Also see associated post Announcing a new VSTS Extension for Starting and Stopping Azure DevTest Labs VMs As I posted recently I have been trying to add more functional tests to the VSTS based release CI/CD pipeline for my VSTS Extensions, and as I noted depending on how you want to run your tests e....

Reporting has always been important for software development, simply put the ability to know what has been done, and what remains to be done. For many teams the out the box reporting within TFS/VSTS dashboards has been enough e.g. sprint burndowns and kanban charts etc. Also TFS has always had SQL Reporting Services (SSRS) to provide rich reporting on a whole host of areas; though in my experience few clients use the out the box reports or customise their own reports....

As time passes I have found there is a need for more cross platform VSTS extensions as there is more uptake of VSTS beyond it’s historic Microsoft platform based roots. Historically most of my extensions have been Powershell based. Now this is not a fundamental problem for cross platform usage. this is due to the availability of Powershell Core. However, Typescript and Node.JS is a better fit I think in many cases....

BlogEngine.Net has served us well as a blogging platform for a good few years. However, it is no longer under active support, so it is time to move on, too much risk of future security issues to ignore the lack of support. After a bit of thought we decided on WordPress as a replacement. OK this has had its own history of problems, but it has an active community and is well supported and in the Azure Marketplace....