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.
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)
That’s it for today’s overview – I’m going to post the corresponding 3 detailed blog posts in the following few days.