2018-2019 Microsoft Most Valuable Professional (MVP) award

Monday, 2 July 2018

I first received Microsoft's MVP award in October 2015. My most recent renewal just occurred on July 1st (aka the early hours of July 2nd here in Adelaide), which was a really nice way to start the week. My 4th consecutive year of being an MVP.

Microsoft MVP Logo


To quote the confirmation email, it was given "in recognition of your exceptional technical community leadership. We appreciate your outstanding contributions in the following technical communities during the past year: Visual Studio and Development Technologies"

For me, that's leading the Adelaide .NET User Group, occasional blogging here, speaking at user groups (and the odd conference) and open source contributions. I like to think that the things I do that have been recognised are things that I would be trying to do in any case.

It isn't something I take for granted. A number of MVPs I know didn't make the cut this year - and it's always a bit of a mystery why some continue and some don't.

I'm also aware that should my own (or Microsoft's) priorities change in the future, then it may no longer be for me. But for now, I really appreciate receiving the award and hope I can make the most of the opportunities it gives me.

Migrating Redmine issues to VSTS work items with the REST API

Friday, 22 June 2018

Redmine is an open-source project management/issue tracking system. I wanted to copy issues out of Redmine and import them into a Visual Studio Team Services project.

Extracting issues can be done by using the "CSV" link at the bottom of the Issues list for a project in Redmine. This CSV file doesn't contain absolutely everything for each issue (eg. attachments and custom data from any plugins). Another alternative would be to query the database directly, but that wasn't necessary for my scenario.

To migrate the data to VSTS you can use a simple PowerShell script, making use of the VSTS REST API.

You'll need to create a Personal Access Token. Be aware that all items will be created under the account linked to this token - there's no way that I'm aware of that you can set the "CreatedBy" field to point to another user.

Notice in the script how we handle different fields for different work items types (eg. Product Backlog Items use the 'Description' field, whereas Bugs use 'Repro Steps'), and for optional fields (eg. not all Redmine issues had the 'Assignee' field set).

The full set of fields (and which work item types they apply to) is documented here. If you have more fields in Redmine that can be mapped to ones in VSTS then go ahead and add them.

Get programming in F#

Monday, 11 June 2018

I’m really interested in learning more about functional programming. It isn’t something I knew much about, but the benefits of reducing mutability (and shared state) promoted by functional languages and functional style are enticing.

To that end, I recently bought a copy of Isaac Abraham’s new book “Get programming in F#. A guide for .NET Developers”.



I have no background in functional languages at all, so I was looking for a “gentle” introduction to the F# language, without getting hung up on a lot of the functional terminology that seems to make learning this stuff a bit impenetrable for the newcomer. This book delivers.

The structure of the book is in 10 “units”, which in turn are broken down into separate “lessons” (each lesson is a separate chapter).

Here's my notes from each unit:

Unit 1 – F# and Visual Studio

Unit 2 – Hello F#

Unit 3 – Types and functions

Unit 4 – Collections in F#

Unit 5 – The pit of success with the F# type system

Unit 6 – Living on the .NET platform

Unit 7 – Working with data

Unit 8 – Web programming

Unit 9 – Unit testing

Unit 10 – Where next?

VSTS and TeamCity – Wrapping up

Sunday, 7 January 2018

Part 4 in a series on integrating VSTS with TeamCity

Wouldn't it be great if TeamCity and VSTS had full builtin support for each other? Well yes, yes it would! Maybe that will happen soon.

If I knew Java well, I could probably have a go at writing a TeamCity addin that encapsulates most of the what the pull request server does - but the idea of spending a few weeks getting up to speed with Java/TeamCity development doesn’t excite me that much.

TeamCity 2017.2 adds VSTS Git support to the Commit Status Publisher build feature. I haven’t been able to try this out yet (due to some other bugs in 2017.2 preventing me from upgrading), but it is possible this could remove or reduce the requirement for the build completion handler.

VCS post-commit hook

Now you've seen how to to use the APIs for TeamCity and VSTS, you might also want to implement another optimisation - adding a VCS post-commit hook. You add an additional service hook in VSTS that notifies TeamCity that there's a code change so that TeamCity knows it should grab the latest commit(s).
  1. In VSTS Project Settings, go to the Service Hooks tab
  2. Click '+' to add a new service hook
  3. Select Web Hooks
  4. In Trigger on this type of event, select Code pushed
  5. Optionally, review the Filters and just check the Repository (and branch) that should trigger the event.
  6. In the URL, enter something like https://www.example.com/app/rest/vcs-root-instances/commitHookNotification?locator=vcsRoot:(type:jetbrains.git,count:99999),property:(name:url,value:%2Fbuildname,matchType:contains),count:99999
    the locator can vary depending on your individual requirements
  7. Enter the username and password to authenticate with TeamCity
  8. Set Resource details to send, Messages to send and Detailed messages to send to None
  9. Click Test to confirm that everything works.

The nice thing about this is that rather than TeamCity blindly polling VSTS, VSTS is telling TeamCity when it has something of interest.

VSTS with TeamCity – Configuration

Wednesday, 3 January 2018

Part 3 in a series on integrating VSTS with TeamCity

Now that we've created the pull request server, we need to configure VSTS and TeamCity so that they can send event messages to it.

VSTS

If you followed the steps in the sample tutorial, this will be familiar.
  1. Go to the Service Hooks tab for your project
  2. Click on the + icon
  3. Choose Web Hooks and click Next
  4. Select Pull request created.
    New Service Hooks Subscription dialog window screenshot
  5. If appropriate, select a specific repository and click Next
  6. In URL, enter the URL that VSTS will use to connect to the pull request server, including a query string that defines which TeamCity build should be queued.
    Eg. If the pull request server is hosted at https://www.example.com/pullrequestserver and the TeamCity build type id is My_CI_Build then you’d use https://www.example.com/pullrequestserver?buildTypeId=My_CI_Build
  7. In Username and Password, enter the credentials that will be used to authenticate with TeamCity
  8. Leave Resource details to send as All.
  9. Set Messages to send and Detailed messages to send to None
  10. Click on Test to try it out.
  11. Click on Finish to save this service hook.
  12. Repeat these steps to create another service hook for Pull request updated, also setting the Change filter to Source branch updated.
With the service hooks in place, you can now go to the Branches page, and click on the … (more actions) icon and choose Branch policies.
Selecting branch policy from more actions menu


The Add status policy button should be enabled, and clicking on that you should be able to find the pull request server listed in the drop down.

TeamCity

To allow TeamCity to call the pull request server, you will need to install the Web Hooks plugin for TeamCity. With that in place, go to the build configuration page in TeamCity, and you’ll see a new WebHooks tab.
  1. Click on add build Webhooks, then Click to create new WebHook for this build and add a new web hook for the project
  2. In the URL, enter the URL that TeamCity will use to connect to the pull request server.
    Eg. If the pull request server is hosted at https://www.example.com/pullrequestserver, you would use https://www.example.com/pullrequestserver/buildComplete.
  3. Set the payload format to Legacy webhook (JSON)
  4. Clear all the trigger events except On Completion Trigger when build successful and Trigger when build fails
  5. Click Save

In the VCS Root settings for the VSTS Git repository, set Branch Specification to
+:refs/heads/(master)
+:refs/pull/*/merge


We don't need TeamCity to trigger the builds for the pull request branches as the pull request server will be queuing those builds, but we do still want TeamCity to trigger the master builds.

In the build configuration VCS Trigger, set the Branch filter to +:<default>

With all that configuration done, creating a new pull request in VSTS should now trigger a branch build in TeamCity. When the build completes, the status is posted back to VSTS, allowing the pull request to be completed by merging the changes into master.