Just published a new VSTS extension with a couple of tasks in it. The aim to to help formalise the end of a release process. The tasks Allow you to set the retension ‘keep forever’ flag on a build (or all builds linked to a release) Update increment a build variable e.g. all or part of a version number, in a build (or all builds linked to a release) The first just replicates functionality I used to have in house for builds ...
I have been using Visual Studio Code for PowerShell development, but got a bit behind on reading release notes. Today I just realised I can make my Integrated Terminal a Code a PowerShell instance. In File > Preferences > user Settings (settings.json) enter the following // Place your settings in this file to overwrite the default settings { // The path of the shell that the terminal uses on Windows. "terminal.integrated.shell.windows": "C:\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe" } Now my terminal is a PowerShell instance, and you can see it has loaded by profile so POSH Git is work as well ...
I recently posted on my development process for VSTS Extensions, it has been specifically PowerShell based build ones I have been working on. During this development I have come across a few more gotcha’s that I think are worth mentioning 32/64 bit The VSTS build agent launches PowerShell 64bit (as does the PowerShell command line on dev PC), but VSCode launches it 32bit. Whilst working my StyleCop extension this caused me a problem as StyleCop it seems can only load dictionaries for spell checking based rules when in a 32bit shell. So my Pester tests for the extension worked in VSCode but failed at the command line and within a VSTS build ...
I wanted to add some level of static analysis to our Typescript projects, TSLint being the obvious choice. To make sure it got run as part of our build release process I wanted to wire it into our SonarQube system, this meant using the community TSLintPlugin, which is still pre-release (0.6 preview at the time of writing). I followed the installation process for plugin without any problems setting the TSLint path to match our build boxes ...
I thought I had a problem with our TFS Lab Manager setup, 80% of our environments had disappeared. I wondered if it was rights, was it just showing environments I owned? No it was not that. Turns our the issue was a UX/Scrollbar issue. I had MTM full screen in ‘Test Center’ mode, with a long list of test suites, so long a scroll bar was needed and I had scrolled to the bottom of the list ...
Background I am finding myself writing a lot of PowerShell at present, mostly for VSTS build extensions. Here I hit a problem (or is it an opportunity for choice?) as to what development environment to use? PowerShell ISE is the ‘best’ experience for debugging a script, but has no source control integration – and it is on all PCs Visual Studio Code has good Git support, but you need to jump through some hoops to get debugging working. Visual Studio PowerShell tools, are just too heavy weight, it is not even in the frame for me for this job. So I have found myself getting the basic scripts working in the PowerShell ISE then moving to VS Code to package up the task/extensions as this means writing .JSON too – so awkward ...
This is a copy of the guest post done on the Microsoft UK web site published on the 7th June 2016 This is a revised version of a post originally published in August 2014. In this revision I have updated version numbers and links for tools used and added a discussion of adapting the process to support VSTS. The code for this post can be found in my GitHub Repo In the past I’ve written on the theory behind migrating TFVC to Git with history. I’ve since used this process for real, as opposed to as a proof of concept, and this post documents my experiences. The requirement was to move an on-premises TFS 2013.2 Scrum Team Project using TFVC to another on premises TFS 2013.2 Scrum Team Project, but this time using Git. ...
Microsoft asked my to revise my August 2014 article on ‘Migrating a TFS TFVC team project to a Git team project’, this revised version is now live on their web site. The changes in the revision are updated links for tools, and information on how to use the technique with VSTS now some work item customisation is available.
Background Most projects will have a range of tests Unit tests (maybe using a mocking framework) running inside the build process Integration/UX and load tests run as part of a release pipeline and finally manual tests In a recent project we were using WebTests to provide some integration tests (in addition to integration tests written using unit testing frameworks) as a means to test a REST/ODATA API, injecting data via the API, pausing while a backend Azure WebJob processed the injected data, then checking a second API to make sure the processed data was correctly presented. Basically mimicking user operations. ...
Struggling to manage those DevTest VM in Azure? Finding it hard to standardise your VMs and get the right things installed? Burning through your Azure credit too fast because you forgot to switch things off? Well Azure DevTest Labs has just been released for general availability, might will just be the thing to help, have a look.