I just spent the day at Microsoft Connect 2017, a one day conference in New York City. There were a few headline technologies and announcements worth noting but the platform that really caught my eye was Visual Studio Team Services (VSTS). One reason VSTS got my attention was that it was previously something I had discounted. In a world of modern cross platform open source GIT-based development it wasn’t clear that the organisation behind Team Foundation Server (TFS) was going to hit the mark. I came away though, surprised and impressed with the way Microsoft has embraced and packaged the concepts and technologies of pipelines-based development.
TFS was designed to support top down enterprise sales – with a message of command and control of development processes and software artefacts. VSTS however is coming from a different design point. It’s a platform developers themselves might chose. In support of that thesis – YAML-based config for pipelines as code, a new Command Line Interface (CLI), and a clean new documentation wiki supporting markdown – with content stored in GIT (dogwhistle!). Creating a scaffold for a devops pipeline with a couple of clicks is well implemented, and should make life easier for teams. Developers should be developing, not spending all their time configuring tools. VSTS feels like something the developers I know might build. It maps pretty well to GitOps.
gitops – modern release management with a focus on pipelines, observability, and control. or something like that.
— Grumble Bundle (@monkchips) November 17, 2017
I spoke to Brian Harry, the corporate VP responsible for VSTS, and he said he appreciated my take because Microsoft had pivoted, starting about 3 years ago, to a new design point looking at bottom up adoption by developers, rather than corporate mandates. Yesterday’s VSTS release is a culmination of some of that work. It’s always nice to hear someone echo Stephen’s New Kingmakers thesis.
VSTS supports about 500 third party tools, which is critical in a fragmented market – including Gradle, Jenkins, Maven etc. I have written about the race to own the pipeline, and the need to support a wide range of tools before.
VSTS has slick tooling for canarying, with easy configuration of rules-based branched deployment across multiple platforms. It is built with forking as a given, but with policy-based “release gates”. Microsoft itself does canarying for its releases, and tracks Twitter sentiment for feedback on new releases before opening up new functionality to all users. At first glance some of the tooling looks to be all about control, but one of the points made was that developers are not always comfortable making pull requests given onerous code reviews – gated reviews add policy to make devs more confident, beyond unit testing etc that their new code will pass muster. Fork to a private repo, meet some standards, then make the pull request. Even the language of the VSTS team was telling – in the morning sessions Microsoft said the design point was to create a “beautiful pull request experience”. Focusing on developer experience, making tools that map to the choices modern developers make, enabling enterprises to keep their developers happy with control – these are all good things. In terms of Social Coding, there was a nice demo in the keynote when Donovan Brown showed how you could share a GIF with the team when shipping some code.
Microsoft was also able to show off its engineering chops by announcing it will partner with GitHub to drive adoption of Git Virtual File System (GVFS), which Microsoft built so that it could use Git with its own huge code bases.
The team also did a good of explaining how it used VSTS to build VSTS. Within Microsoft the team has a reputation for staying on track with its sprints, meeting its targets, which is kind of what you’d hope for in a tool designed to improve software velocity and quality. In terms of customer adoption I spoke to a top tier financial services company that has just rolled out VSTS. One interesting angle was that Microsoft had assigned an engineer on its team to deal directly with the account – engineer to engineer communication made the roll out easier.
The broader market context is that IT shops are currently in a period of transformation. Everyone wants to get better at writing software. The drive to continuous integration and deployment means that companies are looking at new tooling for what we used to call application lifecycle management. In conclusion, while it shouldn’t surprise us Microsoft builds good tools, the renewed focus on developer experience is good to see.
Microsoft paid for my travel and expenses to Connect.
For disclosure Microsoft is also a client, but this is an independent analysis.
No Comments