Azure DevOps (TFS/VSTS) vs GitLab
On this page
On September 10, 2018 Microsoft renamed VSTS to Azure DevOps and by Q1 2019 will rename TFS to Azure DevOps Server, and upgrade both with the same new user interface.
Azure DevOps (VSTS) is a hosted cloud offering, and Azure DevOps Server (TFS), is an on-premises version. Both offer functionality that cover multiple stages of the DevOps lifecycle including planning tools, source code managment (SCM), and CI/CD. However, first development focus will be to Azure DevOps (SaaS). Their project manager shared that they are releasing on a 3-4 week pace. This seems evident based on their published roadmap. The same project manager also shared that Azure DevOps Server (TFS) will be 3-4 months behind on adopting new features (also evident by their published roadmap). They are both from the same code base.
As part of their SCM functionality, both platforms offer two methods of version control.
Git (distributed) - each developer has a copy on their dev machine of the source repository including all branch and history information.
Team Foundation Version Control (TFVC), a centralized, client-server system - developers have only one version of each file on their dev machines. Historical data is maintained only on the server.
Microsoft recommends customers use Git for version control unless there is a specific need for centralized version control features. https://docs.microsoft.com/en-us/vsts/tfvc/comparison-git-tfvc
This is noteworthy given that in June of 2018 Microsoft purchased GitHub, the Internets largest online code repository. This deal closed Oct 26th, 2018.
Because the Azure DevOps suite is so wide, similar to GitLab, an overview can be helpfull in understanding what we're dealing with. Go to this overview page for more details.
- Microsoft can use it's huge customer base to gain access to sell Azure DevOps. And not just it's current VSTS and TFS customers, but any of it's customers buying enterprise software.
- Microsoft converted their large software organization to use DevOps methods, so they are a solid example of their tooling working for that, and they are sharing widely about their journey (ie. their credibility is rising in this space)
- Microsoft has lots of technology partners, which might provide a potential leg up in integrations
- Microsoft is one of the few competitors that has products which cover most of the SDLC stack, even if it's not yet all called "Azure
- No security scanning built in to SDLC offering (see Positioning below for talking points on this)
- Cloud vendor lock-in is a concern and the burden of proof they won't do it is on Microsoft
- VSTS and TFS have been out for a while. If a customer is not happy with it, then the name change and/or potential price drops won't fix the underlying tool issues.
- ephemeral - Azure Pipelines as code (.yaml) is a different pipeline than the ones defined using the UI - evidence
- ephemeral - can’t link work items (Issues) with builds - evidence
- ephemeral - YAML pipeline definition is still a preview feature - evidence
- New pipelines is priced by parallel jobs - hard to know how much need and complicates sales
- Security scanning is built-in to GitLab, for the one single price, and integrated into one UI. With MS, they are all via integrations, most of which you have to pay a second vendor for. The results are not integrated in. Hop to 2nd vendor’s UI for result details. Causes more friction, higher over-all costs, multiple tool configuration and maintenance requirements, and disjointed visibility.
- GitLab provides #1 in market of self-managed Git repos, built-in. MS provides their own Git repo, which is not market leading.
- GitLab is available self-managed and hosted with full functionality released for both at the same time. TFS (self-managed) is 3-4 months behind Azure DevOps (SaaS) releases.
- Microsoft is also a provider of cloud services, which is their money maker. High possibility of vendor lock-in.
Don't rely on
- GitLab offers Forrester Top rated CI from 2017 wave report - MS rated just bellow us (lower in current offering), but as strong in strategy. It is still good to point out our leadership rating in this area (MS will also!) but don't count on it as a differentiator.
- "GitLab is better for .net shops" - GitLab can do .net, but it isn't better than Microsoft in this area. For example, GitLab's binary repository does not currently support NuGet packages (.net specific packaging mechanism), and GitLab does not have built-in facilities for building NuGet packages.
- Azure DevOps
- Azure DevOps announcement blog
- Visual Studio Team Services
- Team Foundation Server)
- Azure DevOps public roadmap and release history
- Azure DevOps general positioning deck
- Regarding the rename and repackaging of VSTS to Azure DevOps:
Microsoft customers wanted the company to break up the Visual Studio Team Services (VSTS) platform so they could choose individual services, said Jamie Cool, Microsoft's program manager for Azure DevOps. By doing so, the company also hopes to attract a wider audience that includes Mac and Linux developers, as well as open source developers in general, who avoid Visual Studio, Microsoft's flagship development tool set.
- Lots of emphasis on cross platform (windows, Mac, Linux), and free macOS CI/CD is pretty rare.
- All paid plans include unlimited stakeholder users who can view and contribute to work items and boards, and view dashboards, charts, and pipelines
- From https://azure.microsoft.com/en-us/blog/introducing-azure-devops/
Azure DevOps represents the evolution of Visual Studio Team Services (VSTS). VSTS users will be upgraded into Azure DevOps projects automatically. For existing users, there is no loss of functionally, simply more choice and control. The end to end traceability and integration that has been the hallmark of VSTS is all there. Azure DevOps services work great together.
As part of this change, the services have an updated user experience.
Users of the on-premises Team Foundation Server (TFS) will continue to receive updates based on features live in Azure DevOps. Starting with next version of TFS, the product will be called Azure DevOps Server and will continue to be enhanced through our normal cadence of updates.
- HackerNews comments saying it's just a rebrand - PM for AzureDevOps responding:
PM for Azure DevOps here (formerly VSTS). It is a rebranding, but it's more than merely a rebranding. We're breaking out the individual services so that they're easier to adopt. For example, if you're just interested in pipelines, you can adopt only pipelines.
- From a call with a prospect Bank:
- Went with Azure DevOps because
It's platform agnostic, it's in the cloud, great capabilityality, tons of functionality, it does what we need it to do. We like it a lot. It really has nothing to do with Microsoft. Microsoft is very agnostic and open source embracing now, so that the old Java vs .Net thing is kind of over.
- Appealed to a shop that was "more Java than Microsoft technologies". But they had lots of the Microsoft development suite already, and trusted where Microsoft is going.
- Azure DevOps is dropping new releases every sprint (2-3 weeks). Their roadmap is public: Azure DevOps public Roadmap and Release History
- Went with Azure DevOps because
- What does the migration path look like from Azure DevOps to GitLab for SCM and CI/CD??
- SCM migration - Available tools to migrate without losing repo history. Like with any product, centrally managed -> Git takes training.
- CI/CD migration - A little tougher. Most existing will be using build pipelines and release pipelines created through UI. Conversion is task by task reconstruction of pipelines, and potential combining into one on GitLab. Azure DevOps pipeline as code is new, although Microsoft is starting to push it as the default now.
- Azure DevOps Services Pricing
- Azure Pipelines Only Pricing
- Azure DevOps On-prem = See TFS Pricing
- Current VSTS and MSDN subscribers get different levels of Azure DevOps. Details can be found at Azure DevOps for Visual Studio subscribers
Visual Studio ‘Professional Version’ is the most comparable to GitLab since Visual Studio ‘Enterprise Version’ includes extras outside the scope of DevOps (such as MS Office, etc).
Visual Studio Professional can be purchased under a ‘standard’ or ‘cloud’ model.
- Standard = $1,200 year one (retail pricing), then $800 annual renewals (retail pricing)
- Cloud - $540 per year
Under their ‘modern purchasing model’, the monthly cost for Visual Studio Professional (which includes TFS and CAL license) is $45 / mo ($540 / yr). However, extensions to TFS such as Test Manager ($52/mo), Package Management ($15/mo), and Private Pipelines ($15/mo) require an additional purchase.
A TFS license can be purchased as standalone product, but a TFS license (and CAL license) is also included when you buy a Visual Studio license / subscription.
MS pushes Visual Studio subscriptions and refers customers who are only interested in a standalone TFS with a ‘classic purchasing’ model to license from a reseller.
Excluding CapEx and Windows operating system license, a standalone TFS license through a reseller in classic purchasing model is approximately $225 per year per instance. The approximate Client Access License is approximately $320 per year.
Commit graph and reporting tools
GitLab provides commit graphs and reporting tools about collaborators’ work.
The most comprehensive import feature set
GitLab can import projects and issues from more sources (GitHub, BitBucket, Google Code, FogBugz, Gitea and from any git URL) than GitHub or any other VCS. We even have you covered for your move from SVN to Git with comprehensive guides and documentation.
Wiki based project documentation
A separate system for documentation called Wiki, is built right into each GitLab project. Every Wiki is a separate Git repository.
Within a commit view or a merge request diff view, and with respect to a specific location of an image, you can have a resolvable discussion. Have multiple discussions specifying different areas of an image.
Merge Request Commit Discussions
Comment on a commit within the context of a merge request itself
Create merge request from email
Create a merge request from email by sending in the merge request title, description, and source branch name.
Lock down continued discussion in an issue or merge request as a Master role or higher, to prevent further abuse, spam, or unproductive collaboration.
First time contributor badge
Highlight first-time contributors in a project.
Preview your changes with Review Apps
With GitLab CI/CD you can create a new environment for each one of your branches, speeding up your development process. Spin up dynamic environments for your merge requests with the ability to preview your branch in a live environment.
Multiple approvals in code review
In GitLab, to ensure strict code review, you can require a specific number of approvals on a merge request by different users before being able to merge it. You can undo an approval by removing it after the fact.
Ease of migration from other providers
GitLab lets you easily migrate all repos, issues and merge request data from your previous provider.
Search files with fuzzy file finder
GitLab provides a way to search a file in your repository in one keystroke.
Fast-forward merge with option to rebase
With this setting at the project level, you can ensure that no merge commits are created and all merges are fast-forwarded. When a fast-forward merge is not possible, the user is given the option to rebase.
Squash and merge
Combine commits into one so that main branch has a simpler to follow and revert history.
Import from GitLab.com
Import projects from GitLab.com to a private GitLab instance.
Limit project size at a global, group, and project level
Ensure that disk space usage is under control.
When a project requires multiple sign-offs, GitLab Enterprise Edition enables you to make sure every merge request is approved by one or more people. Merge request approvals allow you to set the number of necessary approvals and predefine a list of approvers that will need to approve every merge request in a project, and in-turn improve your code’s quality.
Create merge requests and @mention team members to review and safely merge your changes.
Merge conflict resolution
Preview merge conflicts in the GitLab UI and tell Git which version to use.
Reject unsigned commits
GitLab Enterprise Edition Premium allows you to enforce GPG signatures by rejecting unsigned commits.
Verify that a push only contains commits by the same user performing the push.
Git has smaller size requirements
A single repository in Git is typically a number of times smaller than the same repository in SVN.
Working with multiple people on the same file can be a risk. Conflicts when merging a non-text file are hard to overcome and will require a lot of manual work to resolve. With GitLab Enterprise Edition Premium, File Locking helps you avoid merge conflicts and better manage your binary files by preventing everyone, except you, from modifying a specific file or entire directory.
Merge when pipeline succeeds
When reviewing a merge request that looks ready to merge but still has one or more CI/CD jobs running, you can set it to be merged automatically when the jobs pipeline succeeds.
Revert specific commits or a merge request from the UI
Revert any commit or a single merge request from GitLab’s UI, with a click of a button.
A branch in Git contains the entire history that preceds it. It’s also created or moved towards instantly and easily shared.
Granular permissions for branches you want to protect.
Contribute to projects faster by using the Web IDE to avoid context switching in your local development environment. The Web IDE is integrated with merge requests and GitLab CI so that you can resolve feedback, fix failing tests and preview changes live with client side evaluation without leaving the Web IDE.
Store and share code snippets to engage in a conversation about that piece of code. You can embed snippets on any blog or website using a single line of code.
Merge request versions
View and compare merge request diffs from the merge request UI.
Inline commenting and discussion resolution
Code or text review is faster and more effective with inline comments in merge requests. Leave comments and resolve discussions on specific lines of code. In GitLab, Merge Request inline comments are interpreted as a discussion. You can configure your project to only accept merge requests when all discussions are resolved.
Cherry-pick any commit in the UI by simply clicking the Cherry-Pick button in a merged merge request or a specific commit.
View a list of the latest commits, merges, comments, and team members on your project.
Be notified by email, Slack, or ToDos anytime there are changes to an issue or merge request.
GPG Signed Commits
Sign commits and prove that a commit was performed by a certain user.
Work in Progress merge requests (WIP)
Prevent merge requests from accidentally being accepted before they’re completely ready by marking them as Work In Progress (WIP). This gives you all the code review power of merge requests, while protecting unfinished work.
Restrict push and merge access to certain users
Extend the base functionality of protected branches and choose which users can push or merge to a protected branch.
Granular permissions for tags you want to protect.
Built-in and custom project templates
When creating a new project, you can choose to kickstart your project from a predefined template that already has some working example code and CI preconfigured. In addition, you can define a custom project templates by assigning a group. Child projects of this group are available as templates when creating a new project.
Create projects with Git push
Push new projects to the desired location and a new private project will automatically be created.
If you feel there are inaccurate statements in this comparison, please edit this page or propose edits by creating an issue. When creating an issue, please use the "Comparison page" template and assign to @dangordon to ensure we see your suggested changes. You can also send an email to email@example.com with your suggested edits if you're unable to create an issue or edit this page.
We strive for technical accuracy and will review and update this post for inaccuracies as quickly as possible.