Microsoft Azure DevOps OverviewUNIXBusinessApplication

Microsoft Azure DevOps is the #1 ranked solution in top Release Automation tools, #1 ranked solution in top Enterprise Agile Planning Tools, and #2 ranked solution in top Application Lifecycle Management Suites. PeerSpot users give Microsoft Azure DevOps an average rating of 8.0 out of 10. Microsoft Azure DevOps is most commonly compared to Jira: Microsoft Azure DevOps vs Jira. Microsoft Azure DevOps is popular among the large enterprise segment, accounting for 67% of users researching this solution on PeerSpot. The top industry researching this solution are professionals from a computer software company, accounting for 18% of all views.
Microsoft Azure DevOps Buyer's Guide

Download the Microsoft Azure DevOps Buyer's Guide including reviews and more. Updated: November 2022

What is Microsoft Azure DevOps?

Microsoft Azure DevOps is a cloud service that enables developers to collaborate on code development projects and create and deploy applications quicker than ever before. The service helps unite developers, project managers, and software development experts through a collaborative experience while using the application. For the users' convenience, Azure DevOps offers the user cloud services through Azure DevOps Services or an on-premises service using Azure DevOps Server. In addition, it supports integration with additional services and adding extensions, including the ability for the user to create their own custom extensions. 

Azure DevOps provides a variety of unified features that can be accessed through their web browser or IDE client, such as:

  • Azure Pipelines - Develop and deploy services to support ongoing application integration and delivery. Azure pipelines, which work with almost every project type and most languages, will automatically test code projects in order to make them available to others.

  • Azure Artifacts - Share packages and integrate package sharing between teams. Packages include NuGet, npm, and Maven, in addition to other private and public sources. Developers can now share and consume packages with other developers from different public registries.

  • Azure Repos - Offers source control of your code through Team Foundation Version Control (TFVC) or Git repositories. Developers can now keep track of any changes that are made in their code over the course of their project.

  • Azure Test Plans - Offers continuous and manual/exploratory app testing through several tools. Test Suites, or a collection of Test Cases, are grouped together in a container called a Test Plan.

  • Azure Boards - Provides a suite of Agile tools to track work, support planning, code defects, and general issues while using Kanban and Scrum software. Teams are in need of tools that are flexible and will help them grow. Azure Boards is a service that helps developers manage their software projects. 

Benefits of Microsoft Azure DevOps

Microsoft Azure DevOps offers many benefits, including:

  • A quick setup and easy deployment
  • An elastic scale
  • Exceptional security
  • No-maintenance operations
  • Effortless collaboration through domains
  • The ability to create and deploy products faster than traditional software

Reviews from Real Users

Microsoft Azure DevOps stands out among its competitors for a variety of reasons. Two major ones are its ability to forecast how long each task will take and the ability for users to follow the entire development process.

PeerSpot viewers note the effectiveness of this solution. An executive chief operating officer for a cloud provider notes, “We can forecast tasks and the number of hours a task will take and can compare it with how long a task actually takes.” 

Carlos H., a product and system director at SPCM, writes, “I think the most usable thing is that you can follow the whole progress of the development process. This makes it very useful for us.”

Microsoft Azure DevOps was previously known as Azure DevOps, VSTS, Visual Studio Team Services, MS Azure DevOps.

Microsoft Azure DevOps Customers

Alaska Airlines, Iberia Airlines, Columbia, Skype

Microsoft Azure DevOps Video

Microsoft Azure DevOps Pricing Advice

What users are saying about Microsoft Azure DevOps pricing:
  • "The reason that customers are going to the cloud is that it provides the ability to reduce the license cost. For example, when purchasing Office 365 it is bundled with Word, Excel, PowerPoint, Access, and many other applications. In the past, purchasing a license was approximately $600. Today it's only $35 or $45 per customer, per client, or per user, plus the storage. It's less expensive for companies today, to use something, such as Microsoft Azure DevOps, and provide the software to all the employees needing a license. It's better to go with the cloud than just to buy the licenses by themselves."
  • "The solution costs $5 or $10 per user, per month."
  • Microsoft Azure DevOps Reviews

    Filter by:
    Filter Reviews
    Industry
    Loading...
    Filter Unavailable
    Company Size
    Loading...
    Filter Unavailable
    Job Level
    Loading...
    Filter Unavailable
    Rating
    Loading...
    Filter Unavailable
    Considered
    Loading...
    Filter Unavailable
    Order by:
    Loading...
    • Date
    • Highest Rating
    • Lowest Rating
    • Review Length
    Search:
    Showingreviews based on the current filters. Reset all filters
    Assurance Manager at a energy/utilities company with 5,001-10,000 employees
    Real User
    Robust functionality, good integration, continually enhanced, and easy to scale
    Pros and Cons
    • "They have been lately adding features to the services on a regular basis. Every two weeks, they are adding functionality to Azure DevOps Services to match it with what Azure DevOps Server or on-prem would offer. So, we continue to get more robust functionality. My favorite right now is that they are starting to open up the API availability within Azure DevOps Services. Another thing that I like about Azure DevOps is that you can use it with any of the products that are on the market. You can integrate it with Jenkins and other open-source products to complete that fully functional CI, CD, CT, CM, and CS pipeline. It continues to enhance."
    • "We are currently in the process of moving all of our on-prem to the cloud platform. We are trying to make that move and host the majority of our DevOps services in the cloud because the cloud is where most of the things are going nowadays. However, the process of this transfer is not straightforward, and it could be a lot easier. Microsoft hasn't provided the maturity for migration tools. It could be a lot easier in that respect. I want to see them continue to advance the API capabilities. They could add some more robust functionality to the administrative layer within ADO services. There are a lot of configuration elements that you need to take care of at the organization level and the project configuration level from an administrative capacity. When you're dealing with process templates and things of that nature, you have to do them all manually. Being able to automate some of that using scripts or API functionality would be really nice."

    What is our primary use case?

    We're doing a full continuous integration (CI), continuous delivery (CD), continuous testing (CT), security, delivery, and monitoring.

    We're currently using TFS 2013, TFS 2017, Azure DevOps Server 2019 update one, and Azure DevOps services, which is the SaaS cloud platform. I manage all of these.

    It is deployed on Azure DevOps Server and Azure Services' private cloud.

    What is most valuable?

    They have been lately adding features to the services on a regular basis. Every two weeks, they are adding functionality to Azure DevOps Services to match it with what Azure DevOps Server or on-prem would offer. So, we continue to get more robust functionality.

    My favorite right now is that they are starting to open up the API availability within Azure DevOps Services. 

    Another thing that I like about Azure DevOps is that you can use it with any of the products that are on the market. You can integrate it with Jenkins and other open-source products to complete that fully functional CI, CD, CT, CM, and CS pipeline. It continues to enhance. 

    What needs improvement?

    We are currently in the process of moving all of our on-prem to the cloud platform. We are trying to make that move and host the majority of our DevOps services in the cloud because the cloud is where most of the things are going nowadays. However, the process of this transfer is not straightforward, and it could be a lot easier. Microsoft hasn't provided the maturity for migration tools. It could be a lot easier in that respect.

    I want to see them continue to advance the API capabilities. They could add some more robust functionality to the administrative layer within ADO services. There are a lot of configuration elements that you need to take care of at the organization level and the project configuration level from an administrative capacity. When you're dealing with process templates and things of that nature, you have to do them all manually. Being able to automate some of that using scripts or API functionality would be really nice.

    For how long have I used the solution?

    I have been using this solution for about nine years.

    Buyer's Guide
    Microsoft Azure DevOps
    November 2022
    Learn what your peers think about Microsoft Azure DevOps. Get advice and tips from experienced pros sharing their opinions. Updated: November 2022.
    653,584 professionals have used our research since 2012.

    What do I think about the stability of the solution?

    It has actually been pretty stable. Some of the early gen ones were not so stable. Before Microsoft started communicating with the end-users, they would make changes in the middle of the workday, which was a bit frustrating because things would change, which would impact the end customers because they weren't expecting that change. Microsoft wouldn't communicate with tenant administrators and tenant owners, but now, Microsoft has gotten a lot better about articulating their roadmap and communicating when those kinds of changes are coming down the pipeline. We are now able to communicate that out to our tenants and the end-users working within our projects. There is a lot better communication in that respect, which makes it easier for us to make customers aware of what might be coming, what is going to cause changes for them, what are the timeframes in which those things are going to hit their views, and what to expect from those things and additional functionalities.

    What do I think about the scalability of the solution?

    For the cloud, it has been really good. For on-prem too, it is easy enough to scale out. TFS also has always been pretty easy to scale out.

    In terms of the number of users, currently, we're in a transition because we were just acquired by another company. So, we're leaving our parent company, and we're going to a new company. The numbers that I have are in flux. Our current numbers are at about 600 for just our existing or old company. I've been asked to stop onboarding my users and projects until we move our current organization into our new operational tenant in the new company, but I'm projecting that we'll have between 2,000 to 4,000 people.

    How are customer service and support?

    I use it all the time. They're very good when you get to the right queue. So, when it is working, it is great. I would rate them a nine and a half out of ten because I always think people have room for improvement, but they've been very good and supportive.

    It works great for us especially now because we've kind of been divested from our old company to our new company. When we were with our old company, it was a little bit mired because of the way our enterprise architecture was. My requests didn't go to a North American team. It went to an EU team, and then I had to work within EU hours to get support, whereas I am in North America. That was a little tricky. Our old parent company was parented in the UK, Ireland, and Scotland.

    Which solution did I use previously and why did I switch?

    I've used other solutions in tandem, and I have been an administrator for them. For example, I've used Jira and Confluence products, which is Atlassian. I've also used Remedy, but I'm not sure if they're still in the project management. I have also managed HP Performance Center and Tricentis. I've actually been administrating these for the last two years for this company.

    I also use UCD, which is another very similar product. It does a lot of the same things and is also agnostic, just like Azure DevOps. You can use both of these with any of the products that are on the market.  

    How was the initial setup?

    It is pretty straightforward on the administrative side, but I've been working with this technology for a long time. It really falls in line with the majority of Microsoft products. If you're familiar with the Microsoft stack, it follows their pretty standard setup. You go through a similar process. It is just about knowing the nuances that Microsoft has when you're doing a farm configuration or a farm setup and the recommended prerequisites before you get started.

    If we're talking about new end-users who are going from an older version of TFS to Azure DevOps Server or Azure DevOps Services, there is going to be a bit of a delta because the technology is different. There is a slight learning curve. Of course, it has got fancier bells and whistles and a jazzier user interface. It has softer edges and things have moved from left to right. Things that you found on the left side have again moved back over to the right side for administrative or usability functions. Your security elements and the things that you used to see on the left side have again switched back to the right side. These are the kinds of nuances about which you would need to educate your end-users. You need to get them used to the boards and how to use those. If your company is transitioning from a CMI model to an Agile model, it is going to be very important for the folks who are administrating your projects and your project managers to know how to configure the projects themselves, how to use Teams, and how to use permissions. Security becomes even more important because a lot of that really influences how you see the information within your project, and how you manage your boards, your sprints, and the work items that you allocate to your scrums or sprint users.

    As you're going through different stages of your project, you have your pipelines and repos where your more development-centric users are going to be. I try to allocate out two different kinds of users that we're going to have and target them when I'm educating my folks. You have a kind of power user, and you have your regular contributor user. It is important to make this distinction because there are folks who are going to be doing basic or just regular contributor work. They will just contribute to the work items that are on a board or within a sprint. You're also going to have users who need to be slightly elevated, which is going to be that basic plus test plan. You need to understand how those affect your subscription and billing towards that subscription and how to manage that when they're not actively using it. You need to monitor this and enroll them back to a stakeholder so that you're not constantly incurring costs against your pay-as-you-go subscription costs. Everything is pay-as-you-go once you get into the cloud.

    What other advice do I have?

    I would ask those who are looking into implementing Microsoft Azure DevOps if they are already on the Microsoft stack of products. If they are, I would highly recommend them to use Azure DevOps Services or Azure DevOps, because they're already paying for that as part of their E-agreement. So, they should take full advantage of that because it is part of their licensing agreements. They should exploit what they're paying for because they are already paying a lot of money for Microsoft products.

    Both UCD and ADO are the best products in the current DevOps space right now. They're both agnostic, and you can plug and play and integrate them with the majority of the tools in the market. You can integrate them with Jenkins and other open-source products, and open-source is where everything is going when you move to the cloud. Having that flexibility and viability within your company and business, no matter whether you're a small or large company, is a huge benefit. That will allow you to be flexible and deliver to on-prem or container.

    Microsoft is extremely flexible, and they are listening to feedback and hearing what customers are saying. I've worked with Microsoft for almost 20 years now, but I took kind of a two-year sabbatical. Most of that time, I was developing out their SharePoint Online O365 platform. I stepped away for two years and then I transitioned over to DevOps because they really weren't taking feedback that was being provided by customers, and they were ignoring the customer experience, but their new CEO has kind of refocused Microsoft's outlook on the customer experience and is putting the priority back where it needs to be. They're doing a much better job in terms of incorporating feedback. They're continuing to advance and advent their product, and they are keeping ahead of and staying in touch with what technology is doing from a CI/CD pipeline perspective. This is why I am looking forward to continuing to use them.

    I would rate Microsoft Azure DevOps a nine out of ten.

    Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
    PeerSpot user
    Service Delivery Manager at a comms service provider with 1,001-5,000 employees
    Real User
    Top 20
    High level protection, scales well, but more customer feedback updates needed
    Pros and Cons
    • "The most valuable features of Microsoft Azure DevOps are high-level protection. The protection is very important to the customers to prevent eavesdropping. eavesdropping is when a hacker tries to get into the solution. With this solution is it difficult for them to do it."
    • "Testing is very important. Microsoft Azure DevOps tests very well. However, DevOps teams need to be aware of what they are impacting when someone updates anything on the system."

    What is our primary use case?

    I work for a telecommunication company that offered television via IPTV. 

    IPTV is an internet protocol television, such as AT&T U-verse or Fios from Verizon.

    All of the IPTV systems are proprietary, meaning that's not open to the customer, only to the infrastructure. Before Microsoft Azure DevOps, customers only use what are called set-top boxes. When you are deploying Microsoft Azure DevOps, you don't need the set-top box anymore. You only need a client that can go in, but you have to deploy it. You have to understand what the customer has and what they needed to have in place for on-premise, hybrid, or in production.

    Microsoft Azure DevOps does not use the set-top boxes. You have something else that is called OTT or over the top. What that means is the deployment that you're going to do depends on the client the customer is going to use. The deployment has to be tested, and that's why we have the different deployments available, on-premise, cloud, and hybrid.

    What is most valuable?

    The most valuable features of Microsoft Azure DevOps are high-level protection. The protection is very important to the customers to prevent eavesdropping. eavesdropping is when a hacker tries to get into the solution. With this solution is it difficult for them to do it.

    In the hybrid deployment, you can test everything. The customer was perfectly happy that developed the code, and when they put it in the hybrid Microsoft Azure DevOps and tested it as if it were in real production. That's the part that I've really enjoyed the most, is seeing how a product that was developed by the customer was tested perfectly. If something is wrong, we come back to Microsoft Azure DevOps for whatever they need to do. If they need to go deeper, they can use TFS which is part of DevOps and show it to the program manager or developer.

    What needs improvement?

    Microsoft Azure DevOps needs to be updated in my time. In the application that I was managing myself in the deployment and support, it was updated every six weeks. The customer had new features or new batches. Batching is an update of the software. Unfortunately, some of the DevOps or some of the people that were working on that part, do not have the final experience from what customers have. This is something that I did with several teams in Microsoft. We told the product unit manager if you want to understand what is happening from a customer standpoint you need to start from the beginning. Having customers find a problem can not be the only way to find issues to resolve them. 

    Testing is very important. Microsoft Azure DevOps tests very well. However,  DevOps teams need to be aware of what they are impacting when someone updates anything on the system.

    For how long have I used the solution?

    I have been using Microsoft Azure DevOps for approximately 

    What do I think about the stability of the solution?

    It's important to know what kind of DevOps you are going to have. If they're going to work with Microsoft Azure DevOps, they need to understand the solution very well. They cannot just start doing things because they wanted to try and do them.

    What do I think about the scalability of the solution?

    Microsoft Azure DevOps is scalable if you have everything in place, such as the service map and processes. Before you do anything, you have to understand what the impact will be on the customer.

    We had over 10 million people using this solution worldwide. I have worked in many countries, such as the Americas, Canada, and Chile. Many of our product groups were in China, India, France, and Israel.

    Which solution did I use previously and why did I switch?

    I have used Amazon AWS previously.

    When I compare when Microsoft Azure with Amazon AWS. The two of them offer the same features. You have the storage, performance, connectivity, et cetera. However, on the hybrid, Microsoft Azure DevOps is a lot better than Amazon AWS because you can emulate it perfectly. The hop counts matter, which is how many times one communication connects on its travels from one device to another.

    How was the initial setup?

    There are three ways to deploy Microsoft Azure DevOps. To set up all three deployments is very similar but different. The on-premise deployment is where the customer owns the code. What Microsoft Azure DevOps does lets you develop your code, and when you have finished your code, you have to put it in the cloud for the hybrid. Then you can test it in an environment that is similar to production. I was in charge of making sure that everything was set up correctly.

    I was involved from the beginning of the implementation. I'm a project manager myself too. I don't have certification, but I've been doing project management all my life. One important element when doing the implementation is the voice of the customer. No matter what you're configuring or setting up, if the voice of the customer is not there, but the voice of the business and the employees is, that is only two-thirds of what you have to do.

    For example, I want my customers to run this application even if they are in the jungle. If they have access to WiFi, cellular signal, or hotspots, they can have access to anything that Microsoft Azure DevOps can give to them. Except they need a client, and that's the other part. You need to understand what clients the customers are going to need. The clients depend on three things. You need to know the infrastructure of the customers, their immediate needs, and the needs of their customers. We're developing something for the customer who has customers. Unfortunately is not only DevOps, it's everything. DevOps is only one part.

    DevOps has one issue. There are components that are produced and supported by other teams somewhere else. Service maps are very important to develop with DevOps teams. When we develop the service map, they know what to do. However, some DevOps do not like to have service maps, because they say that they know what to do. That's what the problem is, they need to understand that they're not alone.

    What about the implementation team?

    I have worked with integrators, vendors, resellers, consultants, and in-house teams.  

    You have to be a very good project, delivery, and program manager, in order to understand how to work with vendors.

    For example, you need to know how to work with people who, are going to cable a house, building, or something similar. You need to understand specifically what are the requirements that they have as a company. Additionally, you need to understand the company to know the requirements of the customers. If you are not familiar with any one of those, the deployment is going to be a total fiasco. You have to know what is going on. 

    You have to know the vendor. The vendor can tell you a lot. For example, when the materials are available, if there is a problem with the supply chain, what do in this circumstance. The vendor knows about the RMS or the return of the devices. You have to know everything from the deployment, such as RMS to return back, refunds, purchase orders, and goods received.

    What was our ROI?

    The return on investment from Microsoft Azure DevOps depends on how many customers you have and how fast are you going to be able to have something ready for your customers.

    I have a customer who wanted to start quickly on the cloud. They have about three million customers working in one area, and only when 100,000 started did they receive a return on investment. It was not immediate but in approximately a year or a year and a half, they had a return on investment with every single customer.

    What's my experience with pricing, setup cost, and licensing?

    The reason that customers are going to the cloud is that it provides the ability to reduce the license cost. For example, when purchasing Office 365 it is bundled with Word, Excel, PowerPoint, Access, and many other applications. In the past, purchasing a license was approximately $600. Today it's only $35 or $45 per customer, per client, or per user, plus the storage. It's less expensive for companies today, to use something, such as Microsoft Azure DevOps, and provide the software to all the employees needing a license. It's better to go with the cloud than just to buy the licenses by themselves.

    There are some additional costs. You pay for how much space you are using. If you don't use too much space, then the price will be very little. If you use a lot of space, you have to pay for it. Additionally, they offer readiness training. It is not included directly in what is called a statement of work when you are doing business with customers. This is when things can be a little more difficult because it can be expensive for customers if they want to change deployments from on-premises to cloud or hybrid.

    What other advice do I have?

    The voice of the customer is very important. Develop the software based on the voice of the customer.

    I rate Microsoft Azure DevOps a seven out of ten.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Flag as inappropriate
    PeerSpot user
    Buyer's Guide
    Microsoft Azure DevOps
    November 2022
    Learn what your peers think about Microsoft Azure DevOps. Get advice and tips from experienced pros sharing their opinions. Updated: November 2022.
    653,584 professionals have used our research since 2012.
    IT Project Manager at a energy/utilities company with 10,001+ employees
    Real User
    Integrates well with other tools, and enables us to perform different functions within one tool
    Pros and Cons
    • "I like the fact that there is built-in Power BI. Both are Microsoft tools. So, you can incorporate dashboard capabilities."
    • "The tool was developed for Agile project methodology, but I've noticed that there has also been a try to incorporate what is typically done in MS Project, which is for more sequential Waterfall projects. The problem with that is that it is half-baked for Waterfall projects. If you're going to do it, then either go all the way and allow us to use the tool for both or don't do it at all."

    What is our primary use case?

    It is used to manage our projects. We basically maintain what would be the equivalent of our project schedules for various projects. So, we capture or create user stories to identify elements that need to be accomplished for the delivery of a project and to track who is responsible for it and the level of effort. We aggregate that within the tool and report out to leadership about the status of when we anticipate completion.

    We are using its latest version.

    How has it helped my organization?

    Its integration with different functions has been very helpful. Previously, we had Microsoft Project schedules, and we did our reporting by using Excel and PowerPoint presentations. We also did testing tracking in other tools, such as HP ALM. Our source code was on Teams Foundation Server. All that can now be done within DevOps, which is a huge benefit. Things that we used to do in different tools can now be done in one tool. 

    What is most valuable?

    I like the fact that there is built-in Power BI. Both are Microsoft tools. So, you can incorporate dashboard capabilities. 

    I also like the integration with the other toolsets, such as Outlook and GitHub. You can do your testing and check your source code within the same tool. That's definitely something really good.

    What needs improvement?

    The tool was developed for Agile project methodology, but I've noticed that there has also been a try to incorporate what is typically done in MS Project, which is for more sequential Waterfall projects. The problem with that is that it is half-baked for Waterfall projects. If you're going to do it, then either go all the way and allow us to use the tool for both or don't do it at all.

    One thing we had to customize ourselves was to create the critical path. You can't do your project dependencies within the tool. We tried using the tool for a Waterfall project, and we had to find a custom approach to do that because. There should be some functionality for the reporting and dependency tracking for the Waterfall projects.

    For how long have I used the solution?

    I have been working with this solution for two to three years.

    What do I think about the stability of the solution?

    So far, so good. It has definitely been sized appropriately for our use. We haven't had any issues with it.

    What do I think about the scalability of the solution?

    We've only been using it for about three years, and so far, it seems to be able to adapt to our growth. We're maturing into it. We're moving in the direction of using it more, and I feel confident that it'll scale appropriately.

    We have at least a hundred people using the tool. There are different degrees of people who are using it. Some people are using it in the read mode or view mode to keep themselves informed of where things are. We have some project managers who actually use the tool, and then we have a couple of administrators. I'm one of the administrators for our program. I have a couple of vendor or partner folks who are also administrators. We also have a development team that does some customizations on the dashboard and the Power BI reports that we do. These are pretty much different roles or layers that we have.

    We do grant developers access to be able to make their own updates within the tool. Typically, project managers or scrum masters do that, but we also have some team members who are on these projects and have enough understanding of how the tool works and how we're using it. They are able to do their own reporting and their own updates on their statuses.

    In terms of plans to increase its usage, we're moving in that direction. Most of our projects are done in Microsoft waterfall project management schedules, but we are being encouraged to move over to more of an Agile approach on our project methodology. Our mandate is that if you're going to do anything Agile, use the DevOps tool.

    How are customer service and technical support?

    I have not interacted with them. We have a sort of layer for support. I have had to reach out to one of the three resources that we have. He is our true admin at the company who had to reach out to their support, but it has been seldom, at least from my experience.

    Which solution did I use previously and why did I switch?

    I used Jira while working with a vendor that we had here for one of our projects. They brought that tool from their practice. We were doing that because we had not yet moved to DevOps. After they rolled it out at the organization level, the mandate was to stop using Jira and switch over to Azure DevOps. There are a lot of benefits to Azure DevOps over Jira, but Jira is the one that has a lot of market share on that side.

    How was the initial setup?

    I wasn't involved in that, but I do know that, just like many tools, there is a learning curve that was associated with that. I have used Jira before, so I had more or less an understanding because it is very similar to Jira, but I know that for other people I work with, it was a completely new concept to use something like this.

    For its maintenance, we have a small team. We have about three individuals who do the backend support. So, it is minimal. Obviously, if they have any escalations, then they do go to Microsoft, but we haven't had that happen. It was very minimal. There are plugins that are available to enhance kind of some capabilities of the tool. When we ask for that type of functionality, these three individuals have been able to implement plugins for us.

    What other advice do I have?

    It is an Agile tool. We were using the tool calling that we were Agile, but we were really doing things in the Waterfall methodology. It was our square peg in the round hole, and that's where I realized that we didn't have the capabilities in DevOps to use it as a Waterfall tool, which makes sense because Agile is a different approach. We've evolved since then, and now, we're doing a bit more Agile when we use the tool. So, a tool is just a tool. There has to be that thinking alignment. Otherwise, it is a square peg in a round hole, and it doesn't quite fit. Your organization and your team have to understand that. Just using the tool doesn't make you agile.

    The only problem we had was when we rolled this out, we didn't realize how Waterfall we really were. So, I had to go back and have PMs create additional data elements for us to capture what we really wanted to capture to report in Waterfall. Dependencies weren't tracked, and we had to go back. It almost felt like we had to do rework, and people weren't too happy about that.

    I haven't used its mobile device capabilities, but that's definitely something that I would hope to evaluate in the future. 

    I would rate Microsoft Azure DevOps an eight out of 10. Overall, I'm pleased with the tool, but there is definitely some room for improvement.

    Which deployment model are you using for this solution?

    Private Cloud

    If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

    Microsoft Azure
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    PeerSpot user
    Mitch Tolson - PeerSpot reviewer
    Director of Robotics at Fresh Consulting
    Real User
    Top 10
    Customizable, easy to manipulate, and offers a single source of truth
    Pros and Cons
    • "The extensibility of the work item forms and customizations as well as the backend API to query the data, et cetera, and manipulate the data programmatically are all very valuable aspects of the product."
    • "The UI, the user experience, is challenging for newcomers."

    What is our primary use case?

    When I was working at Microsoft, I was one of the core influencers on the feature set and had deployed this solution internally across several organizations. We used it for anything from its CoreALM feature sets to inventory tracking and workflow management and operation support and finance management. There were a bunch of other scenarios. At its core, it is a database with a front end that easily makes it so that you can create new forms and stuff. Then they expose an API, which means you can do a lot of things with it beyond its core use cases.

    How has it helped my organization?

    It becomes a single source of truth for whatever operation is implemented within it. You can have your product definition in there from a requirements management standpoint and then log in bugs and defect management and RPNs and a bunch of other things. You have this single source of truth as they provide an analytics service, and then also easily tie into Power BI. It's really easy to just look at the health and overall operation of your entire business from a single source.

    What is most valuable?

    The extensibility of the work item forms and customizations as well as the backend API to query the data, et cetera, and manipulate the data programmatically are all very valuable aspects of the product.

    What needs improvement?

    The UI, the user experience, is challenging for newcomers. Once you get it, you get it, and it's not too bad. However, it takes some effort to learn how to work with the system. There's a moderate learning curve. I've used both Jira and Azure DevOps, and I would have that same feedback for both tools.

    The biggest challenge has been that both Azure DevOps and Jira tend to pivot more towards software development and the industry is going more towards full end-to-end product development - hardware and software. These platforms could do a lot more to help support the mechanical, electrical, controls, robotics, and more of the hardware side of things.

    For how long have I used the solution?

    I started using the solution in 2010. It's been about 12 years. 

    What do I think about the stability of the solution?

    I haven't had a problem with stability. There aren't bugs or glitches. It doesn't crash or freeze.

    What do I think about the scalability of the solution?

    When you surpass a terabyte of data from a work item standpoint, certainly there are some limitations in performance as the running is querying that large data set in the backend.

    I've done multiple different deployments. Sometimes, the smaller, smaller deployments have been a handful of five people, and it might be three software devs, a test engineer, a hardware engineer, and a PM. 

    I've also done larger deployments where it's 8,300 people. That was a mix of hardware, software, PMs, firmware engineers, front-end, full-stack devs, mechanical engineers, electrical engineers, et cetera. 

    In the deployment that was 8,300, it's actually still deployed there and growing. Another deployment I was a part of that was a medium deployment - 20 users - has since reduced more due to politics and going back to the front-end, ease of use. There are some folks that it was too high of friction to use it. You can scale it up or down to match your needs.

    How are customer service and support?

    I don't deal with technical support in the traditional sense. I know the developers who've developed it, so I just go talk to them.

    Which solution did I use previously and why did I switch?

    I've also used Jira.

    I previously used SharePoint and Microsoft decided the direction of SharePoint to be less workflow-oriented and less list-oriented and more as a document store. As their roadmap moved away from work management, I've moved over into the TFS/Azure DevOps world.

    I was a Microsoft employee. There was some natural tendency to just go with the Microsoft tool, however, it wasn't a hard, fast requirement when we just looked at the feature sets and stuff. 

    How was the initial setup?

    I've been a developer on the backend. In terms of setting up the product, my answer would be highly complex. If I were just doing it for a core user, set of users, then I would say the setup was relatively frictionless. I would say the one point of ambiguity is for some newcomers if they don't understand the difference between CMMI templates versus Agile, versus Scrum, they'll find it complex. I've seen a lot of new users create dummy projects to then go in and see how each of those is configured from a template standpoint. Work could be done there to just reduce that level of friction.

    In terms of deployment times, I've been on multiple different sides of levels of deployment. From the simple side, I've seen deployments take as little as a couple of minutes. If it's teams of five, for example, they go into the web app, they start up a new project, and boom they're in. They get all the requirements and user stories and all that stuff done. 

    I've also been on the other side where it's been nine months with 22 people working full-time to configure and deploy this system across thousands and thousands of users. It just depends on the size.

    What was our ROI?

    It's hard to put a number on managing the plan of record. I haven't tried to calculate an ROI. It does what it's supposed to and it's more accessible than an Excel sheet.

    What's my experience with pricing, setup cost, and licensing?

    The solution costs $5 or $10 per user, per month. It's a nominal fee.

    I would actually prefer it in that they give you the first five users for free. That little bit of free users goes a long way, just from an initial trial and adoption standpoint. I would encourage them to keep doing things like that.

    If you use the other services - if you use their build and compute engines and stuff like that, they charge some amount for computing and some of their extensions. These are not necessarily Microsoft's extensions. They are third-party ones and they'll charge. Depending on if the feature is core to the product, or it's an extension, it might or might not cost you something extra.

    Which other solutions did I evaluate?

    I've evaluated pretty much every ALM.

    What other advice do I have?

    We're just a customer and an end-user.

    I've used all the versions, starting back with Server 2005. Now I'm just using their online version.

    In terms of advice I'd give to new users, I'd say it goes back to basic change management. Understand who your attractors and detractors are. Lay out the feature sets, ease of use, and things like that. That at least will help detractors become a neutral party as there are always going to be people that create friction within a deployment. Just have an effective change management plan. I've looked at over 12 different ALMs and they all have their pros and cons. It really just comes down to just picking one and going forward with it and learning it.

    I would rate the product at an eight out of ten.

    Which deployment model are you using for this solution?

    Public Cloud

    If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

    Microsoft Azure
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    PeerSpot user
    Software Engineering Manager at a healthcare company with 1,001-5,000 employees
    Real User
    Top 20
    Provides the best full integration feature on the market; our most important tool
    Pros and Cons
    • "This is an all-in-one, one-stop shop, nothing comes close."
    • "Project management could be improved."

    What is our primary use case?

    We're using Azure DevOps Services for three things: First, for project management, second, for storing the source code, similar to GitHub Repository, and finally, we use it as our CICD build server or build environment, which builds for us and runs tests and so on. In general, these are the three main use cases for this product. We are large customers of Microsoft and we're on a corporate level with them. We pay extra for support. I'm a software engineer manager. 

    What is most valuable?

    I like that this solution is all-in-one, a one-stop-shop, it's the killer feature. I haven't seen anything that comes close. I guess GitHub will be close soon, but that's it, there's really nothing right now for that full integration. Other solutions require three tools so this is really a great feature. The solution has a better user interface and better CICD tools compared to what we used previously when we ran TeamCity. I think it scores higher on most things, including better developer ergonomics. Since it's Git-based, there's no training because everyone uses Git. I've found it to also be very customizable so that on all points it's better. This is an important tool for us. 

    What needs improvement?

    This solution is not as good as Jira when it comes to project management and I think they know it, but it's good enough. I'm very used to it now, so I can work more quickly, but I've had colleagues who are very Jira-focused and they don't like Azure DevOps at all. When it comes to the handling of tickets or tasks or the product backlog, Jira is much more customizable and more intuitive. It's an area that Microsoft could improve. 

    The instructions could be a little better. We are doing some weird stuff where we're building some things, including embedded firmware. It wasn't super intuitive to set that up which was an issue although it's something minor and we managed to solve it. I just expected it to be a little easier, although it's not what the solution is built for. We're going a little out of the normal use case. It is a little clunky compared to Jira and hosting your own builds could be a little easier.

    I'm aware that they're putting money into GitHub to add more features around vulnerability scans and statical analysis and so on, basically taking on cloud and what have you, as well as Vericode that we are using. It would be great if it was built into the tool. I get things from other vendors that are provided out of the box, and it would be awesome for me to have that with DevOps. 

    For how long have I used the solution?

    I've been using this solution for several years. 

    What do I think about the stability of the solution?

    The stability of the solution is good. We've had a couple of dashboards out and they have a nice page share where they show what's out and what's not. A few months back they had some issues with the Active Directory and we were pretty much locked out of some things. We lost Teams for a while and we use that a lot in Azure DevOps. It was quickly fixed. Otherwise, I'm very happy with the stability. 

    What do I think about the scalability of the solution?

    The scalability of the solution is good and there's no maintenance required. We're a small operation and we could grow by a factor of 10 and it wouldn't be a problem. This is an SaaS and if you need to take care of it, there's something wrong. We use the solution extensively and soon we'll have almost every piece of software, including all our test automation and embedded firmware there so we'll be increasing usage. 

    Which solution did I use previously and why did I switch?

    The company previously used TeamCity, and I have used Jenkins in the past, the grandfather of everything. Azure DevOps is nicer. Jenkins is very configurable, but a pain. I like Azure a lot more and I think this or something like it, GitHub Actions, for example, is the future.

    How was the initial setup?

    The initial setup is very intuitive. What I think they could work on is the whole permissions model where you have projects and other things which require permissions and which is not very intuitive. You can do almost everything but I want a more granular permissions model that's also easy to maintain. I don't quite like the way it's set up so there's some work to be done there. I think I'd rather do it in text because it's hard to see everything clearly otherwise. If you have a complex permissions system, it's complex to set up and it's not super intuitive. Compared to AWS, which is a very different system, that aspect of Azure is not very intuitive.

    I work in an engineering department so we didn't feel the need to get any help with deployment. If you read the manual, create the sandbox, and test it out you're able to roll it out. It's not that hard. 

    What's my experience with pricing, setup cost, and licensing?

    We're not paying a lot for this product. As developers, we have a Visual Studio license which is basically free. That's how their licensing model works. Then we have a number of stakeholders who need to do edits in the system, but not work with code necessarily. I believe they're paying $5 a month per user. We also have users who only need to read things and don't need code so I set that up for everyone who needs it. We're probably paying a few hundred dollars per month altogether. That's a minor cost for us; we're not currently hosting anything on cloud, so it's a small cost compared to hosting a solution. 

    We ran into a few things where we had to pay more because of the number of concurrent building agents. We had capped it low and the developer was unhappy so we paid a little more to get what we needed and that's been good. I don't like it when you get a big bill and you don't know about it. 

    What other advice do I have?

    I'm somewhat critical of the documentation for certain things, but overall, the documentation is really good. In general, Microsoft is really good at documentation. It's worth taking a few hours to read it and then you'll know a little about how Access works. If you set up a sandbox, you're not going to destroy anything and you'll learn by trying things out. I would still read the documentation and go in parallel so you can at least know enough and be aware that it's safe to get in there.

    We are very heavy users in creating small projects and then sometimes deleting them because they weren't useful but I like that model. Create a little sandbox and go build. We have done our own workflows and they are always tested in a sandbox before going live. That would be my suggestion. 

    I rate the solution eight out of 10.  

    Which deployment model are you using for this solution?

    Public Cloud
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    PeerSpot user
    Chief Operating Officer Executive at a cloud provider with 11-50 employees
    Real User
    Top 10
    Fast, scalable, and stable work planning and code collaboration software; offers a good user experience
    Pros and Cons
    • "Stable and scalable solution for work planning and code collaboration. It's fast, and it offers a good user experience."
    • "The optimization feature in Microsoft Azure DevOps needs improvement. Control over multiple projects could also be improved."

    What is our primary use case?

    We use Microsoft Azure DevOps for management, e.g. managing items that we need to work on, planning activities, connecting to components to get information on how long the developer is working on the items assigned, etc. We use the solution for our projects.

    We have internal users from the development team, and we have the work logs that we need to work on for each customer. We match those to have control over the projects and the budget. We have a component plugged into the solution for the billables and performance delivery. What we don't have yet is optimization, and that is something that needs to be improved in Microsoft Azure DevOps, but the solution has all the activities and the budgeting functions, so the project is working good. We're making an exact component in seven days that we can use with the solution.

    What is most valuable?

    One of the features I found most useful in Microsoft Azure DevOps is that we can use it to plan activities. We use the dashboard to work on the tasks we have, and also use it to find out what could be better. It's also useful when you have many customers and many people working together on different projects.

    In our case, we have one developer working on more than one project within the same day, week, or month, and Microsoft Azure DevOps helps give better control of his schedule, making it easier to find out if the developer still has availability to take on new work. The solution helps us see the work status and availability of team members, making work management and task management better.

    The validation and quality offered by Microsoft Azure DevOps are very good. The user experience is good. The speed of the solution is also good, e.g. the pages load fast.

    What needs improvement?

    The optimization feature in Microsoft Azure DevOps needs improvement.

    Sometimes, having control over multiple projects for a customer could be difficult. If you're a developer, you need to know if you still have time to work on more activities within the day. When you're working on one project for one customer, Microsoft Azure DevOps is great, but when your team is working on different projects for several clients, it may be too hard to handle, e.g. you really need to organize and plan the activities, so planning is another area for improvement in the solution.

    Planning includes budgeting, e.g. creating a budget for each project, especially if the developer is working on multiple projects of customers. You need to have control and see to it that you are within budget, but it can be hard because you can't always see the daily, weekly, or monthly activities of the developer, particularly if the developer doesn't keep the calendar updated. We want to be able to view the complete list of activities of the developer, whether daily, weekly, or monthly, to make planning and budgeting easier.

    I'd also like the Microsoft Azure DevOps Gantt chart to be improved. We need to see in the schedule how to plan the fields out. We have daily activities and we'd like to use the Gantt chart to make our work approach more successful.

    For how long have I used the solution?

    We've been a partner of Microsoft for 10 years, and we've been using Microsoft solutions for 10 years.

    What do I think about the stability of the solution?

    Microsoft Azure DevOps is stable. Sometimes there's a little lag, but the next day, it'll work fine. The solution works fine.

    What do I think about the scalability of the solution?

    Microsoft Azure DevOps is a scalable solution.

    How was the initial setup?

    Setting up Microsoft Azure DevOps was easy.

    What other advice do I have?

    We use Microsoft solutions as part of management. We use Microsoft's platform.

    We use the latest version of Microsoft Azure DevOps for our projects.

    We have 15 people who are in charge of the deployment and maintenance of the solution. Per project, we have one or two developers who utilize Microsoft Azure DevOps: At the beginning, we have the front end developer and the cloud personnel who create the environment, the designer who works to create the right frame, the right materials, the layout, and the design for the project, and at the middle, we have four to five operators.

    The platform works well so we didn't have the need to open a ticket or contact Microsoft technical support.

    I really like Microsoft Azure DevOps, so I recommend it to people who want to start using it. My advice to them is that it's a huge platform, so it won't be easy the first time. When you test the platform, you need to spend time and make an effort to understand how it works, but it's the best solution. It's the top solution. 

    Another advice to new users of Microsoft Azure DevOps is that it's harder to have a macro view of all the processes together. When we needed to cross-match a lot of information from the different processing teams of customers, we found it difficult. You also need to plan well, particularly plan when your developer can work on more than one project. When you have many projects, you need to handle the processes well, e.g. create separate folders for each customer, separate projects, etc., to keep the information separate and be more organized.

    Microsoft Azure DevOps could still be improved more, so I'm rating it an eight out of ten.

    We are a partner of Microsoft, and we use Microsoft solutions. What we recommend to our customers is for them to use the Microsoft environment, server and databases. We work with some of the solutions and technologies from Microsoft.

    Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
    PeerSpot user
    Chief Digital Officer (CDO) at a financial services firm with 201-500 employees
    Real User
    Easy to use, stable, and helps speed up production
    Pros and Cons
    • "Typically the sprints themselves and managing the tasks have essentially eliminated our need for reporting."
    • "Some of the queries, the way they're built, need to be looked at. We need better query tools."

    What is our primary use case?

    We primarily use the solution for our Agile teams, however, we started off using it with our executive suite. Our executive team now meets in sprints every day. Sometimes it's a short 15 minutes, other times it can be up to an hour. We have two-week sprints and daily scrums associated with it. We've also rolled that down from the executive. We've got seven formal Agile teams running throughout the organization across our businesses. We probably have at least 40% of our staff now trained in Agile and using DevOps to execute the projects.

    How has it helped my organization?

    As an Agile team, we're now able to move much faster than we could, even pre-COVID.

    What is most valuable?

    Typically the sprints themselves and managing the tasks have essentially eliminated our need for reporting. That in itself has had a huge effort on the number of meetings. In the past, you would almost wait a month before you could get all the executive teams together. Now, we've got meetings daily. Due to the regular meetings, we're utilizing daily scrums and two-week sprints, and we've been able to move a lot faster than we've ever had before as far as initiatives. 

    Frankly, throughout this whole COVID situation, being able to respond the way we have to some of the changes that were going on has been amazing. I don't think that would have happened if we weren't an Agile team.

    What needs improvement?

    There are a lot of features that we could probably work with a bit differently as we learn more about the tool. Right now, we're just really using it from a task management perspective. We've only been using it a year. There may still be more to learn and unpack.

    Some of the queries, the way they're built, need to be looked at. We need better query tools.

    Being able to report back to boards, to regulators, and the activities and stuff would be helpful. The queries do require somebody else to actually write them. There should, however, be a way to make things a little simpler in that space. Right now it's on us to figure out how to get better at making queries effectively and in such a way we're just not reporting on tasks complete.  

    We track the associated feature story. In many ways you can actually go back and see the story, and see the progress you've made on initiatives due to the fact that you can see all the decisions that have been made along the way. If there's a way that person could dig into that and pull more information or insights, that would be very helpful as it would assist us in improving future projects or even help us forecast on an existing project. 

    For how long have I used the solution?

    I use the solution daily. We launched it in the company in January. We've been using it across all our Agile teams here for 12 months here.

    What do I think about the stability of the solution?

    The stability of the solution is very good. I haven't had issues with bugs or glitches. It doesn't crash or freeze. It's a reliable solution.

    What do I think about the scalability of the solution?

    The solution's level of scalability is good. We're a smaller organization. We've only got 300 people in total, and out of those, probably 40% of our entire staff use the product. About 120 people probably are in there on a daily basis. That's everyone from executives down to programmers. It's extremely cross-functional across our organization.

    How are customer service and technical support?

    I haven't had to reach out to DevOps themselves personally, so I wouldn't have experience there. However, if we ran into any issues, my technology teams would contact them.

    Which solution did I use previously and why did I switch?

    We didn't previously use a different solution. That's why we looked for an automation tool. We switched to DevOps mostly due to the fact that our development team was utilizing DevOps as part of their own Agile operations. A number of teams were also already sort of experienced. There are a number of individuals in the company who were experienced that way, and we had homegrown support in some ways when we launched it. It just made sense to go with DevOps as opposed to bringing in something new.

    How was the initial setup?

    The initial setup wasn't complex. It was pretty straightforward. We didn't run into any issues that complicated the process of implementation.

    Which other solutions did I evaluate?

    We did look at Jira briefly, however, it didn't look that different from DevOps and we knew many of our team members were already comfortable with this solution so we didn't pursue it.

    What other advice do I have?

    We're just Microsoft customers. We don't have any business relationship with the company.

    I'm not sure which version of the solution we're using.

    I'd strongly recommend the solution to other organizations. I can't see us ever reversing back now after being on this for a year.

    Overall, I would rate the solution at an eight out of ten. It's relatively easy to use and it does what we need it to do.

    Which deployment model are you using for this solution?

    Public Cloud

    If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

    Microsoft Azure
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    PeerSpot user
    AndreasSemousu - PeerSpot reviewer
    Technical Sales Manager at Skhomo Technologies
    Real User
    Top 5
    It's a good tool that helps us manage the work our developers and software engineers do on-site, but it has a few things that tick me off
    Pros and Cons
    • "Our technical sales staff and business development people need to know how far the developers are on any product that we're developing. DevOps makes it easier for you to see how far along they are with the work because they have a repository where they store everything. There is a portal where you can see what has been done, what has been tested, what is working, and what isn't. I have a huge dashboard with an overview of what the development team is doing from an executive point of view."
    • "I can't think of any specific things at the moment, but I've run into things that I didn't like. I came across something that I wanted to be changed in DevOps, but I can't remember what it was. It was a particular feature I was looking for that I couldn't find."

    What is our primary use case?

    We are an application development company, so DevOps helps us manage the work our developers and software engineers do on-site. It's convenient for customers because everybody works from home due to COVID.

    DevOps is used within our organization and we also encourage some of our clients who are interested in a development platform to use Azure DevOps, but we have other clients that actually prefer Red Hat or other platforms. We like Azure DevOps, but our cloud environment is AWS. We've done three implementations on AWS without any problem.

    How has it helped my organization?

    Our technical sales staff and business development people need to know how far the developers are on any product that we're developing. DevOps makes it easier for you to see how far along they are with the work because they have a repository where they store everything. There is a portal where you can see what has been done, what has been tested, what is working, and what isn't. I have a huge dashboard with an overview of what the development team is doing from an executive point of view.

    I know exactly what they're working on. If the team is falling behind on a project, there's a project management module where I can see exactly what was supposed to be delivered and what hasn't been. 

    What needs improvement?

    I can't think of any specific things at the moment, but I've run into things that I didn't like. I came across something that I wanted to be changed in DevOps, but I can't remember what it was. It was a particular feature I was looking for that I couldn't find.

    What do I think about the stability of the solution?

    I'm happy with DevOps' stability. I've had problems with the Red Hat environment, but I think it also boils down still to implementation skills. We're a big Microsoft implementer, so we find Azure DevOps to be highly stable.

    What do I think about the scalability of the solution?

    DevOps is highly scalable. Before one of our clients decided to move to the cloud version of DevOps, they decided to try it in a small environment to see if they liked it. Previously, they had Team Foundation Server running on-premises, and we encouraged them to switch to DevOps. We set up a minimal environment and used it as a typical development environment. It wasn't for testing or anything. It was just a mini development environment that replicated their internal chassis.

    Which solution did I use previously and why did I switch?

    Before we started using DevOps, we were using Microsoft Team Foundation Server, which allowed the whole team to share work and collaborate. DevOps does that and a little more.

    How was the initial setup?

    Most of the time we just leave it on the cloud instead of deploying it on-prem, unless a client requests on-prem. In that case, we just replicate the cloud environment in the on-prem environment. There's no real difference, and we've had some clients who change and say they now prefer to have it on the cloud. 

    After the subscription, which took about a day, we had our B environment up and running, and everything was transferred from on-prem to the cloud. In the older days, it would take you about a month. But now, to move, it actually took us, I think, almost a week, because the biggest challenge was moving the data more than the environment. Moving the environment, it took about, I think, a day or two. But the data was a bit of a problem.

    What's my experience with pricing, setup cost, and licensing?

    The cost of Azure DevOps is manageable. You have the option to purchase a license that is per user. You can choose based on the size of your team. For example, you can opt for a volume enterprise license or go for user-based licensing if you don't have a huge number of users. 

    You can start with a smaller package and then scale up as needed. Let's say, for instance, you are a smaller company with about only 10 users of the environment. Then, two months later, you win the Powerball, and you get a billion dollars and bring in a thousand developers.

    You have the flexibility to move from a small-team subscription to a big subscription easily. So you don't necessarily have to take the volume. The licensing model covers all three tiers, whereby you can have a volume license, individual users, or groups. 

    We are using groups, and we've found it affordable because you cancel their license if someone leaves. When we get a new person, we repurchase the license. We pay a monthly subscription, but the annual licenses are cheaper because of the commitment. 

    What other advice do I have?

    I rate Azure DevOps seven out of 10. I would give it a higher rating, but there are a couple of things that tick me off.

    Which deployment model are you using for this solution?

    Hybrid Cloud

    If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

    Amazon Web Services (AWS)
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    PeerSpot user
    Buyer's Guide
    Download our free Microsoft Azure DevOps Report and get advice and tips from experienced pros sharing their opinions.
    Updated: November 2022
    Buyer's Guide
    Download our free Microsoft Azure DevOps Report and get advice and tips from experienced pros sharing their opinions.