Azure DevOps Services vs. Azure DevOps Server
Azure DevOps Services | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
Azure DevOps Services and Azure DevOps Server were formerly named Visual Studio Team Services (VSTS) and Team Foundation Server (TFS). Both offerings provide an integrated, collaborative environment that supports Git, continuous integration, and Agile tools for planning and tracking work.
Azure DevOps Services is the cloud offering that provides a scalable, reliable, and globally available hosted service. It's backed by a 99.9% SLA, monitored by our 24/7 operations team, and available in local data centers around the world.
Azure DevOps Server is the on-premises offering that's built on a SQL Server back end. Companies usually choose on-premises when they need their data to stay within their network or when they want access to SQL Server reporting services that integrate with Azure DevOps data and tools.
Although both offerings provide the same essential services, compared with Azure DevOps Server, Azure DevOps Services offers the following added benefits:
- Simplified server management.
- Immediate access to the latest and greatest features
- Improved connectivity with remote sites.
- A transition from capital expenditures (servers and the like) to operational expenditures (subscriptions).
To determine which offering—cloud or on-premises—meets your needs, consider the following key differences.
Fundamental differences between Azure DevOps Services and Azure DevOps Server
When you're choosing which platform you want, or if you're considering a move from on-premises to the cloud, consider the following areas:
- Scope and scale data
- Users and groups
- Manage user access
- Security and data protection
Differences in specific feature areas
Although Azure DevOps Services is a hosted version of Azure DevOps Server, there are some differences between features. Some Azure DevOps Server features aren't supported in Azure DevOps Services. For example, Azure DevOps Services doesn't support integration with SQL Server Analysis Services to support reporting.
Two of the following additional areas differ in their support:
Are you on Azure DevOps Server and considering moving? Read Migration options to understand your options.
Scope and scale data
Azure DevOps Services scales by using organizations and projects
Azure DevOps Services differs slightly from Azure DevOps Server. There are currently only two options for scoping and scaling
data: organizations and projects. Organizations in Azure DevOps Services get their own URLs (for example,
https://dev.azure.com/fabrikamfiber), and they always have exactly one project collection. Organizations can have many projects within a collection.
We recommend that you create organizations in Azure DevOps Services wherever you would create collections in Azure DevOps Server. The following scenarios apply:
- You can purchase Azure DevOps Services users per organization - Paid users can access only the organization in which the payment is made. If you have users who need access to many organizations, Visual Studio subscriptions can be an attractive option. Visual Studio subscribers can be added to any number of organizations at no charge. We're also considering other ways to make access available to many organizations that are grouped into a single organization.
- You currently have to administer organizations one at a time. This process can be cumbersome when you have many organizations.
Learn more: Plan your organizational structure in Azure DevOps.
Azure DevOps Server scales by using deployments, project collections, and projects
Azure DevOps Server offers the following three options for scoping and scaling data: deployments, project collections, and projects. In the simplest case, deployments are just servers.
Deployments can be more complicated, however, which could include:
- Two-server deployment where SQL is split out on a separate machine
- High-availability farms with lots of servers
Project collections serve as containers for security and administration, and physical database boundaries. They're also used to group related projects.
Finally, projects are used to encapsulate the assets of individual software projects, including source code, work items, and so on.
Learn more: Plan your organizational structure in Azure DevOps.
With Azure DevOps Services, you connect over the public internet (for example,
https://contoso.visualstudio.com). You either authenticate with Microsoft account credentials or with
credentials, depending on your organization setup. You can also set up Azure AD to require features such as multi-factor-authentication, IP address restrictions, and so on.
We recommend that you configure your organizations to use Azure AD rather than Microsoft accounts. This method provides a better experience in many scenarios and more options for enhanced security.
With Azure DevOps Server, you connect to an intranet server (for example,
https://tfs.corp.contoso.com:8080/tfs). You authenticate with Windows Authentication and your Active Directory (AD) domain credentials. This process is transparent and you never see any kind of sign in experience.
Manage users and groups
In Azure DevOps Services, you can use a similar mechanism to provide access to groups of users. You can add Azure AD groups to Azure DevOps Services groups. If you use Microsoft Accounts instead of Azure AD, you have to add users one at a time.
In Azure DevOps Server, you provide users access to deployments by adding Active Directory (AD) groups to various Azure DevOps groups (for example, the Contributors group for an individual project). The AD group memberships are kept in sync. As users are added and removed in AD, they also gain and lose access to Azure DevOps Server.
Manage user access
In both Azure DevOps Services and Azure DevOps Server, you manage access to features by assigning users to an access level. All users must be assigned to a single access level. In both the cloud and on-premises offerings, you can give free access to work item features to an unlimited number of Stakeholders. Also, an unlimited number of Visual Studio subscribers can have access to all Basic features at no additional charge. You pay only for other users who need access.
In Azure DevOps Services, you must assign an access level to each user in your organization. Azure DevOps Services validates Visual Studio subscribers as they sign in. You can assign Basic access for free to five users without Visual Studio subscriptions.
If you use Azure AD groups to give access to groups of users, access levels are automatically assigned at first sign-in. For organizations that are configured to use Microsoft accounts for signing in, you must assign access levels to each user explicitly.
In Azure DevOps Server, all use is on the honor system. To set access levels for users based on their licenses, specify their access levels on the administration page. For example, assign unlicensed users Stakeholder access only.
Users with an Azure DevOps Server/TFS Client Access License (CAL) can have Basic access. Visual Studio subscribers can have either Basic or Advanced access, depending on their subscriptions. Azure DevOps Server doesn't attempt to verify these licenses or enforce compliance.
Security and data protection
Many entities want to know more about data protection when they consider moving to the cloud. We're committed to ensuring that Azure DevOps Services projects stay safe and secure. We have technical features and business processes in place to deliver on this commitment. You can also take steps to secure your data. Learn more in our Data Protection overview.
You customize the work-tracking experience in two different ways, depending on the supported process model:
- For Azure DevOps Services, you use the Inheritance process model, which supports WYSIWYG customization.
- For Azure DevOps Server, you can choose the Inheritance process model or the On-premises XML process model, which supports customization through import or export of XML definition files for work-tracking objects.
- For Azure DevOps Server 2018 and earlier versions, you only have access to the On-premises XML process model.
Although the On-premises XML process model option is powerful, it can cause various issues. The main issue is that processes for existing projects aren't automatically updated.
For example, Azure DevOps Server 2013 introduced several new features that depended on new work-item types and other process template changes. When you upgrade from 2012 to 2013, each project collection gets new versions of each of the "in the box" process templates that include these changes. However, these changes aren't automatically incorporated into existing projects. Instead, after you finish upgrading, you have to include the changes in each project by using the Configure features wizard or a more manual process.
To help you avoid these issues in Azure DevOps Services, custom process templates and the witadmin.exe tool have always been disabled. This approach has enabled us to automatically update all projects with each Azure DevOps Services upgrade. Meanwhile, the product team is working hard to make customizing processes possible in ways that we can support easily and continuously. We recently introduced the first of these changes and more changes are on the way.
With the new process-customization capability, you can make changes directly within the web user interface (UI). If you want to customize your processes programmatically, you can do so through REST endpoints. When you customize projects this way, they're automatically updated when we release new versions of their base processes with Azure DevOps Services upgrades.
To learn more, see Customize your work-tracking experience.
Azure DevOps Services and Azure DevOps Server offer a many tools that give you insight into the progress and quality of your software projects. Included are the following tools:
- Dashboards and lightweight charts that are available in both the cloud and on-premises platforms. These tools are easy to set up and use.
Azure DevOps Services and Azure DevOps Server 2019 also provide access to the following services:
- The Analytics service and Analytics widgets. The Analytics service is optimized for fast read-access and server-based aggregations.
- Microsoft Power BI integration, which supports getting Analytics data into Power BI reports and provides a combination of simplicity and power.
- OData support, which allows you to directly query the Analytics service from a supported browser, and then use the returned JSON data as you want. You can generate queries that span many projects or your entire organization.
To learn more about the Analytics service and future releases, see our Reporting roadmap.
SQL Server Reporting Services (SSRS) reports are available from Azure DevOps Server or TFS when configured with SQL Server Analysis Services.