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.
What?
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:
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:
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 – http://vunvulearadu.blogspot.com/2018/09/how-to-calculate-cost-of-cicd-on-top-of.html
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.
Extensibility
Beside the build-in features there are four mechanisms available to extend Azure DevOps 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.
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
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:
The pricing list can be found on the following list: https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/
Conclusion
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.
What?
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 – http://vunvulearadu.blogspot.com/2018/09/how-to-calculate-cost-of-cicd-on-top-of.html
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.
Extensibility
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:
Pricing
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:
- No. of users
- Type of users that have access
- No. of pipelines
- Hosted type of pipeline (Microsoft-hosted or Self-Hosted)
- Azure Test Plans
- Load Testing Complexity
- Hosting artifacts in a private repository
The pricing list can be found on the following list: https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/
Conclusion
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.
Comments
Post a Comment