Applying DevOps principles to Office Add-In development2 min read

Estimated Reading Time: 2 minutes

As I’m sure you guys are aware, DevOps is a big new movement in IT, that brings Development and Operations together. I recently came across this slide that nicely outlines the four key areas of focus. The ultimate goal is – to bridge the “it works on my machine” syndrome – and make Dev work together with Ops – as far as deployment is concerned – as well as Ops with Dev – for learnings from production operations.

This big shift has of course been triggered by the same company doing development of a product as well as operating it in a SaaS model. Suddenly a lot of companies’ success is no longer tied to selling a ready-to-setup MSI package, but providing a ready to use service, that is being operated by the same people.

Devops2

Recently I’ve been working on an Outlook Add-In with the new JavaScript Office APIs. With the new model – all add-ins are a website with HTML + JS, running on a remote webserver. So to offer the Office Add-In I had to effectively become a tiny SaaS provider as well. The add-in is being rolled out to roughly 100 internal colleagues – within my team – so providing bad quality could have meant a quick loss of credibility! Sounds familiar?

So I decided to use our tooling to implement a tiny DevOps process for the Outlook add-in. I’m going to describe some of the interesting challenges and how we did overcome them in 3 blogposts – one per phase of the DevOps cycle (nothing special in PLANNING, so we’ll skip that).

Phase 1 – Plan:

Really nothing special here, so we’ll skip this.

Phase 2 – Develop & Test (coming soon)

Development was done using Office.JS libraries and Office UI Fabric for some nice pre-built controls.
There’s really a ton of documentation around these, so the focus of the post is on the central BUILD & SOURCE CONTROL part using Visual Studio Team Services.
I did build several custom VSTS build tasks – to make build happen as I wanted it to be…

Phase 3 – Release (coming soon)

To push the end-results of the build to first QA and then PRODUCTION environments, I’ve used VSTS Release Management. Each of these environments being an Azure WebApp. RM is the same engine as BUILD – but with the notion of individual pipelines for each environment. The tasks are interchangeable.

Again I’ve built a custom task which is

  • Office Outlook Add-In Build/RM Task

Phase 4 – Monitor & Learn (coming soon)

Monitoring of web-content can easily be achieved using Azure Application Insights. So I decided to embed that into both the server part on the Azure WebApp, but also the client code in Javascript.

That’s it for today’s overview – I’m going to post the corresponding 3 detailed blog posts in the following few days.

Leave a Reply

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