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. This works, but is it not better to only start the agent VM when it is actually really needed, not when you guess it might be? I need this private agent only when working on my VSTS extensions, not something I do everyday. Why waste CPU cycles that are never used? ...

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. You just provide a few parameters and you are good to go. Well you should be good to go, but there is an issue. The PowerShell used to extract the downloaded Build Agent ZIP file does not work on a non-UI based Windows VM. The basic issue here is discussed in this post by my fellow ALM MVP Ricci Gian Maria. Luckily the fix is simple; I just used the same code to do the extraction of the ZIP file that I used in my previous post. I have submitted this fix as a Pull Request to the DevTest Lab Team so hopefully the standard repository will have the fix soon and you won’t need to do a fork to create a private artifacts repo as I have. Update 1st December 2017 The Pull Request to the DevTest Lab Team with the fixed code has been accepted and the fix is now in the master branch of the public artifact repo, so automatically available to all ...

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.g. trigger sub-builds, you can end up with scheduling deadlocks where a single build agent is scheduling the release and trying to run a new build. The answer is to use a second build agent in a different agent pool e.g. if the release is running on the Hosted build agent use a private build agent for the sub-build, or of course just pay for more hosted build instances. The problem with a private build agent is where to run it. As my extensions are a personal project I don’t have a corporate Hyper-V server to run any extra private agents on, as I would have for an company projects. My MVP MSDN Azure benefits are the obvious answer, but I want any agents to be cheap to run, so I don’t burn through all my MSDN credits for a single build agent. To this end I created a Windows Server 2016 VM in DevLabs (I prefer to create my VMs in DevLabs as it makes it easier tidying up of my Azure account) using an A0 sizing VM. This is tiny so cheap; I don’t intend to ever do a build on this agent, just schedule releases, so need to install few if any tools, so the size should not be an issue. To further reduce costs I used the auto start and stop features on the VM so it is only running during the hours I might be working. So I get an admittedly slow and limited private build agent but for less that $10 a month. As the VM is small it makes sense to not run a GUI. This means when you RDP to the new VM you just get a command prompt. So how do you get the agent onto the VM and setup? You can’t just open a browser to VSTS or cut and paste a file via RDP, and I wanted to avoid the complexity of having to open up PowerShell remoting on the VM. The process I used was as follows: ...

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. The lack of SSRS based reporting on VSTS has been a blocking limitation for some clients, preventing their move to VSTS. Also irrespective of peoples past use of custom reports, most people would like an easier way, than SSRS, to produce custom reports and charts. So enter VSTS Analytics Microsoft’s new free reporting option for VSTS that provide a host of reporting options for dashboards, Power BI and OData. For a great introduction have a look at Gregg Boer’s Channel9 video Visual Studio Team Services Reporting: Dashboards, Power BI, and OData ...

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. This has caused me to revise the way I structure my repo and build my VSTS extensions to provide a consistent understandable process. My old Gulp based process for Typescript was too complex and inconsistent between tasks, it even confused me! My process revisions have been documented in my vNextBuild Github’s WIKI, so I don’t propose too repeat the bulk of the content here. ...

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. ...

Whilst doing some NPM build work for VSTS Extensions I kept getting intermittent EPERM errors about renaming Windows files during NPM install (as discussed on GitHub)l. When you get this it completely blocks any development. As the Github issue discusses there are many possible reasons for this issue, and many proposed potential solutions. However the only one that worked for me was to restart VS Code; as this appeared to be locking the node_modules folder somehow. This was even though I could delete it via Windows Explorer without any problems. ...

I have working on getting a Windows 10 Universal application analysed with SonarQube 6.x as part of a VSTS build. The problem has been that when the VSTS task to complete the SonarQube analysis ran I kept getting an error in the form WARNING: Duplicate project GUID: "8ace107e-8e3c-4a1b-9920-e76eb1db5e53". Check that the project is only being built for a single platform/configuration and that that the project guid is unique. The project will not be analyzed by SonarQube. Project file: E:Build1\_work58sBlackMarble.Victory.Common.Module.csproj … plus loads more similar lines. The exclude flag has been set so the project will not be analyzed by SonarQube. Project file: E:Build1\_work58sBlackMarble.Victory.Ux.Common.csproj … plus loads more similar lines. WARNING: Duplicate project GUID: "1e7b2f4e-6de2-40ab-bff9-a0c63db47ca2". Check that the project is only being built for a single platform/configuration and that that the project guid is unique. The project will not be analyzed by SonarQube. 2017-06-09T15:50:41.9993583Z ##\[error\]No analysable projects were found but some duplicate project IDs were found. Possible cause: you are building multiple configurations (e.g. DEBUG|x86 and RELEASE|x64) at the same time, which is not supported by the SonarQube integration. Please build and analyse each configuration individually. Generation of the sonar-properties file failed. Unable to complete SonarQube analysis. Turns out the issue was that even though my CI build was only set to create an x86|Debug build the act of creating the .APPX package was causing both x64 and ARM builds to be build too, this was too much for SonarQube as it though I had a multiplatform build.. ...

Are you enthused by the all news at Build 2017? Do you want to find out more about VSTS, DevOps and Continuous Delivery? Well why not take the chance to join us on June 17th at Black Marble, or one of the over 25 other venues around the world for the first Global DevOps Bootcamp? The Global DevOps Bootcamp is a free one-day event hosted by local passionate DevOps communities around the globe. Find your local venue on the Global DevOps Bootcamp website or search for Global DevOps Bootcamp on EventBrite ...