Today I have released a major new release, V2, of my VSTS Cross Platform Extension to build release notes. This new version is all down to the efforts of Greg Pakes who has completely re-written the task to use newer VSTS APIs. A minor issue is that this re-write has introduced a couple of breaking changes, as detailed below and on the project wiki oAuth script access has to be enabled on the agent running the task There are minor changes in the template format, but for the good, as it means both TFVC and GIT based releases now use a common template format....

The Issue Azure is a highly resilient service, and VSTS has excellent SLAs. However, a question that is often asked is ‘How do I backup my VSTS instance?’. The simple answer is you don’t. Microsoft handle keeping the instance up, patched and serviceable. Hence, there is no built in means for you to get a local copy of all your source code, work items or CI/CD definitions. Though there have been requests for such a service....

I recently, whilst changing a CI/CD release pipeline, updated what was previously a private version of a VSTS extension in the VSTS Marketplace with a version of the VSIX package set to be public. Note, in my CI/CD process I have a private and public version of each extension (set of tasks), the former is used for functional testing within the CD process, the latter is the one everyone can see....

Whilst trying to install an MSI package we kept getting the errors 2755 and 1632 ‘The Temp folder is on a drive that is full or is inaccessible’. After much fiddling we found the problem was that the %systemroot%installer folder was missing. Once this was manually re-added the MSIs installed without a problem. The actual TEMP folder setting was a red herring

My existing VSTS CI/CD process has a problem that the deployment of a VSTS extension, from the moment it is uploaded to when it’s tasks are available to a build agent, is not instantiation. The process can potentially take a few minutes to roll out. The problem this delay causes is a perfect candidate for using VSTS Release Gates; using the gate to make sure the expected version of a task is available to an agent before running the next stage of the CD pipeline e....

I am currently looking at the best way to migrate a large legacy codebase from TFVC to Git. There are a number of ways I could do this, as I have posted about before. Obviously, I have ruled out anything that tries to migrate history as ‘that way hell lies’; if people need to see history they will be able to look at the archived TFVC instance. TFVC and Git are just too different in the way they work to make history migrations worth the effort in my opinion....

Background Having automated builds is essential to any good development process. Irrespective of the build engine in use, VSTS, Jenkins etc. you need to have a means to create the VMs that are running the builds. You can of course do this by hand, but in many ways you are just extending the old ‘it works on my PC – the developer can build it only on their own PC’ problem i....

I am really pleased that we at Black Marble are again the first UK location announcing that we are hosting an event on June 16th as part of the 2018 Global DevOps BootCamp. As the event’s site says… “The Global DevOps Bootcamp takes place once a year on venues all over the world. The more people joining in, the better it gets! The Global DevOps Bootcamp is a free one-day event hosted by local passionate DevOps communities around the globe and centrally organized by Xpirit & Solidify and sponsored by Microsoft....

I recently released an updated version of my Generate Parameters.XML tool for Visual Studio. This release adds support for generating parameters.xml files from app.config files as well as web.config files Why you might ask why add support for app.config files when the parameters.xml model is only part of WebDeploy? Well, at Black Marble we like the model of updating a single file using a tokenised set of parameters from within our DevOps CI/CD pipelines....

I wrote a post recently Versioning your ARM templates within a VSTS CI/CD pipeline. I realised since writing it that it does not address the issue of if you wish to version your ARM Templates using Semantic Versioning. My JSON versioning task I used did not support the option of not extracting a numeric version number e.g. 1.2.3.4 from a VSTS build number. To address this limitation I have modified my Version JSON file task to address....