Skip to main content

Azure DevOps - Spin-up your software development pipeline

In the last weeks, Microsoft announced a new cloud service available for all – Azure DevOps. The main scope of this post is to identify the core features of this new service and what are the differences between Visual Studio Team Services and Azure DevOps.

Azure DevOps it is a collection of services used during the software development phase. All these services are interconnected between each other and can be orchestrated from one location. There is full support for services like:

  • Task Management and Tracking (Agile boards, including Kanban)
  • Source Control (Git)
  • Build and Release for CI/CD
  • Testing (Load and Performance Testing, manual or exploring testing)
  • Wiki
  • Reporting and custom dashboard capability
  • CI/CD pipelines
  • Extension for integration with 3rd parties

Services Overview
Some services are similar from the functionality perspective with the previous service called VSTS. It is normal because Microsoft replaces the original service (VSTS) with Azure DevOps that has five pilers:

  • Azure Pipelines – CI, testing, deployment system that can connect to any Git repository (cloud or on-premises)
  • Azure Board – tracking capability, including reporting and dashboard
  • Azure Artifacts – hosting capacity for NuGet, npm, Maven
  • Azure Repos – private Git repository
  • Azure Test Plans – test management and capturing information about the defect

A feature that it is useful in the Azure Pipelines is the capability to define a release policy where you can request manual approval (signing) from specific people before releasing a new version in specific environments. Besides this, the release can be manual or automatic, giving us the flexibility to do a manual release for situations where automation it is not possible.

The collaborative services that are part of Azure DevOps are allowing us to define alerts that can notify people or group of people when specific actions are happening inside the system. There is also an integration with Power BI, enabling the management group to create a custom report and obtain insights information about the project and the team.
Most of Azure Services available in this moment is already integrated with Azure DevOps. Enabling us to use and deploy our products on all Azure Services. Beside this, we can do deployment using the traditional mechanism on on-premises or other cloud providers.
The support for Service Hooks extend the default capabilities of Azure DevOps. Using Service Hooks, we can integrate any other services from the market – Extensibility. I was always a big fan of WebHooks because are a simple and powerful way how we can connect and extended system cross the world (internet).
As in VSTS, there is a full support to do a build using Microsoft-hosted agents or using our own agents that can be hosted by Microsoft or by us. You can check a previous post about it –

Things to remember
For source control, we can use the build-in Git repository, hosted inside Azure DevOps or we can use any external Git or TFVC (Team Foundation Version Control System), clients. It is not essential if it is on-premises or in the cloud as long as Azure DevOps can access the repository.
From the planning and board perspective, there are three native board supported by default: Scrum, Kanban, and Scrumban. Beside this, we can customize and modify the board, allowing us to create our own system of work tracking.
The SLA for Azure DevOps is 99.9% with support engineers ready to help us at any moment of the day. To have support 24/7, it is especially important when all your team works around a source control and task management system hosted inside Azure. A few days ago I had a bad experience with a Wiki service offered by another provider that was down for around 2 hours in the middle of the day and the support team from their side was ‘offline.’
There is full integration with Azure AD, enabling us to connect our organization with Azure DevOps. All the security policies that we already have defined inside the organization will be applied automatically inside Azure DevOps.
Under an Azure DevOps instance, we can create one or multiple organization. Each organization can have one or multiple projects. Using organizations and projects, you can replicate your internal structure or your client's structure, allowing you to slit and control the access of your teams.

Beside the build-in features there are four mechanisms available to extend Azure DevOps capabilities:

  • REST API – That can be used to create extensions that communication with Azure DevOps 
  • Service Hooks – Trigger events when specific actions are happening inside our system or vice-versa
  • Visual Studio SDK – Extent existing features of Visual Studio and share it with the rest of the team
  • Visual Studio Marketplace – Provides extensions that can be installed and use on our development or backend systems, providing new capabilities

User Roles
Inside Azure DevOps, there is a clear list of Roles that a user can have. Each Role allows a user to do specific activities or particular access content. Below you can find a high-level overview of the roles available inside Azure DevOps.

  • Software Developer – Change the code and tasks, see history and many more
  • Project Manager – Task management, reporting, queries, use and manage dashboards
  • DevOps – Define and manage builds, unit tests, performance and exploring tests, pipelines, and deployment
  • Stakeholders – Can see tasks and content, provide feedback, but cannot do changes in the code
  • Team Administrator – Board and backlog and any activity at the team level
  • Project Administrator – Full control at the project level
  • Organization Owner – Full control at the organization level, including billing 

VSTS vs. DevOps
We cannot compare this two services because Azure DevOps is VSTS. Microsoft renamed VSTS to DevOps, giving it a new name and new capabilities. There was a renaming of the services. A mapping table can be found below:
Remember that the old interface together with the previous features of VSTS is still available. It is your decision if you want to use Azure DevOps or VSTS interface.

Pricing is a little more complicated to calculate because you need to take into accounts multiple items. I will try to enumerate things that can influence the price at the end of the month:

  1. No. of users
  2. Type of users that have access
  3. No. of pipelines
  4. Hosted type of pipeline (Microsoft-hosted or Self-Hosted)
  5. Azure Test Plans
  6. Load Testing Complexity
  7. Hosting artifacts in a private repository

The pricing list can be found on the following list: 

From Microsoft side, it was a smart choice to do the rebranding because the old VSTS was more than a TFS. The new name with the new capabilities is reflecting more what is now Azure DevOps – a full Azure Services that enable you to control and manage your software development process from development and testing to deployment and QA.


Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…