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

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

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

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

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

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.

I was lucky enough to attended and be on a panel at yesterdays WinOps London conference, it was a different and very interesting view on DevOps for me. I spend most of my time consulting with test and development teams, with these teams it is very rare to come across a team not using source control and they commonly have some form of automated build too. This means any DevOps discussion usually come from the side of ‘how can I extend my build into deployment…’....