My first Azure DevOps Extension

Posted by

On a recent project, we used a physical board to visualise the work we needed to do.

It was taking me a lot of time to export work item data and re-format it into a layout suitable for printing. And then someone would add/update/remove some work items, and I’d have to start again.

This led to me creating an Azure DevOps extension – in my own time – in order have a quick and easy way to print work items, so I could chop them up with a guillotine and give them to the team to use.

Azure DevOps Extension: Board cards for printing

Adds a ‘Print’ tab to Sprint boards, and allows users to select iterations, work item types and areas to print on A4 paper for putting on physical boards..

Board cards for printing on Visual Studio Marketplace.

How I built the extension

  1. I started with the Microsoft “developer a web extension for Azure DevOps” tutorial. This gave me a start with Node.JS too.
  2. I used the Azure DevOps REST clients, for Work and Work Item Tracking, in JavaScript.
  3. I followed the Data Settings and Storage how-to guide. Data is stored in the user scope by Azure.

What I learnt

  1. There’s a really swish IDE from Microsoft, built on Electron with tons of extensions, VSCode. It’s free and open source. Microsoft even makes binary releases of VS Code without MS branding/telemetry/licensing.
  2. JavaScript has changed a fair bit since I last used it. “use strict” is great. As are Promises. And using const (and occassionally let) is way better than var for variables.
  3. Github is easy, until you make a mistake.
  4. There’s a Node.js module for everything.
  5. You don’t always need a Node.js module.
  6. Modular functions that are single purpose are your friend.
  7. I didn’t implement Promises correctly. I may go back and fix that sometime.
  8. When people start using your work, they need you to help them sometimes.
  9. I would make a truly awful programmer.

What I didn’t learn this time

  1. How to implement unit testing and automated testing – I broke the extension frequently (thankfully only in a separate development version).
  2. How to implement a deployment pipeline. Every minor change I made had to be packaged and published manually for me to test. It was slow and irritatingly repetitive

Leave a Reply

Your email address will not be published. Required fields are marked *