Skip to main content

The Benefits of the Azure DevOps Suite

For years there was Microsoft’s Team Foundation Server (TFS) which provided on-premises users the capability to use source control, agile backlogs, test automation and build pipelines. Then Microsoft took TFS and built it as a cloud platform providing it to their own (internal and external) customers as a service under the name Visual Studio Team Services (VSTS). Now, this name always had its issues as lots of companies did not even look at VSTS because “we do not use Visual Studio”. Fair enough, but VSTS, apart from having a nice integration from Visual Studio, did not have much in common with it.

Everything old is new again

On September 10, 2018 Microsoft announced their new “Azure DevOps” suite which supersedes VSTS.

Quick note upfront: Buying this service will not make you DevOps. The service will be able to support your company’s journey to becoming more mature on its DevOps journey, but DevOps is way more than a collection of tools.

What changed though? At first glance, not much.

Diving a bit deeper, quite a bit.

The first thing that changed is the URL users use to access it, instead of company.visualstudio.com it will now be dev.azure.com/company. Redirects are in place, so existing customers should not feel any impact.

Each of VSTS’s components like Code, Build, Release, Test, Work and Package Management have been renamed to Azure Repos, Azure Pipelines, Azure Test Plans, Azure Boards and Azure Artifacts.

In this screenshot an Azure DevOps project has been created that uses all Azure DevOps services. A new feature is now that a project’s administrator can disable certain services for a project. What does this mean?

With VSTS a project had always all services available, whether or not a team used them was not important. However, a lot of teams already have a product for their backlog (like Atlassian Jira for example), use GitHub for their Source Control Management and just don’t require Test Plans or Artifacts. Previously, Microsoft told customers to just not use those services then and make sure users just do not have permission to create anything under those services. Not a very elegant solution.

Now companies can selectively disable services they do not require from the project settings pane.

The User Interface automatically changes to reflect those settings and disabled services are not visible anymore.

The fact that services now can be disabled is big, as before we have seen lots of companies that suddenly had people creating code repositories on VSTS even though the company in general uses GitLab. Companies can now pick and choose the tools they really want. A big win for customers.

In the future customers will be able to selectively acquire each service separately or all as one. Currently, only Azure Pipelines can be bought separately.

Open Source is great

On June 4, 2018 Microsoft announced plans to acquire GitHub for $7.5 Billion USD and the outcry in the Open Source community was big. Or was it just loud?
Anyways, if any company in the near past has shown their commitment to Open Source, then it is probably Microsoft. Even parts of the Azure DevOps service are Open Source, hosted on GitHub, for everybody to look at, and even contribute to.

Not a massive surprise then that Azure DevOps is not precious at all about users using other Source Control products, like GitHub.
If those users are Open Source Projects hosting their code in a public repository on GitHub or a public Azure Repos repository, then there’s even more great news for them. Open Source projects receive build and release pipelines on Azure DevOps pipelines for free with unlimited minutes every month including 10 parallel jobs. Each job has a timeout or maximum runtime of 360 minutes, which is more than enough.

This functionality is already available in the GitHub Marketplace.

With Build pipelines as code (YAML) (in preview at time of writing of 23/09/2018) this means that Open Source projects can now add their build definition into their GitHub repository as “azure-pipelines.yml” and Azure Pipelines will automatically use this source-controlled file to build the project.

Build everything 

Microsoft is making a point of “we’re open” by enabling their customers (paying and free) to build pretty much whatever they want.

You need a Windows build environment? Of course, Microsoft has some of those. In fact, there is a Windows Server 2016 one with Visual Studio 2017 installed, a Windows Server 2012R2 with Visual Studio 2015 and a Windows Server 1803, which will enable customers to run Windows containers.
You need a Linux build environment?  Yes, Microsoft has one of those. There is an Ubuntu 16.04 build agent.
You need to build on macOS? You heard right, there is a hosted build agent running macOS 10.13 available. For free.

These build agents cover almost every common use case that one can think of, and it is all “as a Service”, no need to deploy any infrastructure yourself. Nobody got time for that.

Written by David O’Brien


About David O’Brien

David recently started his own consulting company XIRUS (https://xirus.com.au ) focusing on mainly Microsoft stacks in the cloud, training individuals and companies in all things Microsoft Azure and Azure DevOps (formerly VSTS), also still doing hands-on consulting and infracoding.

He has held a Microsoft MVP award for 5 years including the prestigious MVP for Azure.

A co-organiser of the Melbourne Microsoft Cloud and Datacentre meetup he also regularly speaks at international conferences and combines his interest to travel the world with his passion to share IT stories with the community. David’s personal blog can be found on https://david-obrien.net . In addition to blogging he has also published online training courses on Pluralsight.

 

Select Language