Microsoft Azure DevOps Reviews

I primarily use the solution on projects often. We use it for our Git repository and the CI/CD.

I love how easy the solution is to use. It’s intuitive. I don’t need to reference a manual. Everything is just very naturally laid out.

You can link your tasks and assign people. To me, it just makes sense. The user experience is excellent.

I like the Kanban tasks and their various features. It’s all very straightforward.

The one thing that really stands out to me is how you can filter and how you can do your reporting and filter the tasks and everything by user. Every time I try to do that in Jira, for example, it's a pain.

The stability of the product is quite good.

I’m not sure what needs improvement. I don't even think I'm using everything. There are still a lot of things on the testing side that I'm not using. That said, there's, there's a lot that it can do. I wouldn't even know where to get started on discussing what it needs or lacks.

We did have some brief performance issues, however, that was due to putting everything on one epic instead of breaking a project up.

I’ve been using the solution for about four years now. It’s been a while.

For the most part, the stability is very good. There was one time there was a bit of a performance issue, however, it was just due to the fact that the project manager was overwhelmed. It slowed down and got laggy. We put everything on one story, one epic, and we realized we needed to split it up.

The product can scale. With the projects that I work on I just pick up Azure DevOps. It just makes sense. Everything from the beginning, for example, how the story starts right up to how it gets deployed and everything, is well laid out and you can adjust as needed.

On the project that I'm doing right now, maybe have a team of ten. On other projects, for example, at my previous company, we had a hundred devs or so using it.

Technical support has been very good. We used to call Microsoft and they would help us. They gave great support. We’re quite happy with their responsiveness and level of knowledge.

I also use Jira alongside Azure DevOps. I use both of them.

I find DevOps easier to use and better laid out. I find Jira difficult and confusing.

The initial setup is pretty straightforward.

I can’t speak to the exact pricing. It’s not an aspect of the product I deal with.

We’re a customer and an end-user.

I’m a big fan of DevOps. It’s a good project and I haven’t seen anything else like it.

As we’re on the cloud deployment of the solution, we’re always on the latest version.

I’d advise new users, if they are a Microsoft shop, to choose DevOps over Jira. It just makes more sense.

I’d rate the solution at a ten out of ten.

A common use case of Microsoft Azure DevOps is the use of work items and then connecting them to Git repositories and their updates. It is primarily used for item and code management.

The work items option is incredibly flexible.

There are multiple add-ons available.

It is easy to use.

The entry point is adequate.

When you compare with Jira, there is a lack of progress features.

I would like to be able to customize the product using add-ons or a similar mechanism.

Scalability is an area where they could advance and make changes.

Unfortunately, managing users in Azure is a very complicated issue. We also have a problem with one of their other tools, which is Teams. The Team messaging has caused us some trouble because they have what is called organization, in addition to the users, but it doesn't work very well.

Technical support needs improvement.

I would like to see scalability, dashboards, KPIs, measurements, and some visual management assistance improved in the next release.

I have been working with Microsoft Azure DevOps for one year.

We are using the latest version.

Microsoft Azure DevOps is a stable product.

This solution is used by 20 people in our organization.

It appears to be simple, but based on the work items and project management aspects, I believe there are few options for scaling it up in terms of dashboards and KPIs.

I contacted technical support about managing users in Azure. Unfortunately, they were able to resolve this issue for us.

We tried several times and we did not get the answer we expected to get.

I use Jira as well as TFS.

The initial setup is straightforward. It is simple to install.

Other than the initial setup, it does not require any maintenance.

It was implemented internally.

The majority of the components are reasonably priced. Testing is one of the more expensive components. When you compare it, it is approximately $3 per month for the other components and $45 or $50 for the Testing component. It costs ten times as much as the other components.

I would recommend this solution to others who may be interested in using it.

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

With the query feature, we have to group items, so it becomes difficult for everyone to understand it. It's easier in JIRA, which has filters and other query options. So, I think this query option should be there in the DevOps also. Also, I don't like the DevOps' boards at all. It's more complicated than JIRA, I think. So, DevOps can improve in terms of its boards, work items, and filters. 

Then there is also an issue with user access. We have about 10 to 15 users that we can add to DevOps. But only the first five users have basic level access, and the rest have stakeholder access. That means they can change the task status but not add or do anything. I think Microsoft should remove this restriction from DevOps. With the access restrictions, it's tough for us to add any status for our users or filter anything on the boards. So, Microsoft should add this functionality for the other roles as well.

DevOps is a stable solution.

It's average. It's not better than JIRA. It's average because many things need to be improved by Microsoft in all their products.

Setting up DevOps is easy. 

We pay for DevOps when we use it for our clients. But for personal and internal projects, we can use the free version. But there are restrictions on the trial plan. It should also be available for free use. However, the trial version of DevOps is free for only five basic users. So, I think it should be free for others also. And other extensions like test plan creation should also be available for the basic users, at least. We have to purchase the license for this.

We use both JIRA and DevOps. The main difference between DevOps and JIRA is the test cases. You can have test cases in DevOps but not in JIRA. And, DevOps has advantages in terms of executing those test cases. You can develop releases from DevOps but not from JIRA. At the same time, JIRA's jQuery is the best. I don't like the grouping and filtering in DevOps. 

I rate Microsoft Azure DevOps seven out of 10. I would recommend it to others. It's a nice and helpful tool.

All the artifacts are tightly integrated into the repository where you have changed tracking, and you can enforce policies. You can improve the quality of your deliverables. You can actually see the progress you're making towards your goal, and you can even forecast how soon a feature can be completed in the future. So, it's that tight integration of bringing all the parties together right from the project managers to the developers, to the system admin who does the deployment that helps achieve the goal of DevOps. That is, the ease of realization of this DevOps ideal is possible.

Most developers and project managers choose the Microsoft tools to begin with because of familiarity, and these new tools are almost an extension of the tools you're already familiar with. There's a lot of knowledge transfer, which helps, rather than bringing in a new product line.

Also, with Azure DevOps there is tight integration to Excel and Office tools so that you can actually even use Excel to do Azure DevOps type tasks. Excel will automatically update the Azure board, your tasks, your company boards, etc. So, there is that condition and familiarity for users.

What I like about it mostly is the tools. You don't need a degree to use them. Also, there's not too heavy a reliance on the CLI.

Right now, they tend to have a limit of 1,000 tasks per sprint, and some of their web-based boards, such as the Kanban boards, no longer display tasks. Once you hit over a certain number of task limits, you need to increase those limits. Depending on how big the sprints you're running are, once you hit that 1,000 limit, you now have to start grouping tasks together. It doesn't allow you to track granularly. When you go to the boards and you are rendering the task board, it gets slower to go over that 1,000 limit. If they could improve that to, maybe, 10,000 and still have good performance, that'd be great.

I've been using it for eight years.

The version we use right now is the 2020 version, but usually, we try and keep within the last two versions.

Depending on the organization, it can be deployed on-premises or as a cloud solution, usually with Microsoft Azure as the cloud provider.

It's very, very stable.

I've used it in organizations with multiple departments using the same installation, and it's scalable. We have about 20 users in multiple departments.

Microsoft support is excellent. Even when you don't have support for some lines, you can call them, and a lot of times, they'll give you what's called a grace case. This means that although you don't have a support contract on a product, they'll help you for free.

Normally, when you call and don't have a support agreement, Microsoft will still charge you an hourly rate to give you an engineer to work with you.

Microsoft Azure DevOps just provides better integration than Jenkins does. I've been in this industry for 27 years. The whole ecosystem and the fact that most of the developers are already using Visual Studio make Microsoft Azure DevOps a good option, along with the entire integration from the project management side, to the development side, to the repository side, and to the deployment side.

Installing Microsoft Azure DevOps is straightforward. You can have everything set up in three or four hours. It's pretty simple.

I've used Jenkins in the past and a group of source repository. I've also used SourceSafe and GitLab.

To run it, to use the tool the way it's designed, you need someone who understands Scrum or Agile project management.

I have used GitLab and other pipeline tools like Jenkins. Azure DevOps combines all of them together, and it beats all of them at everything they do.

On a scale from one to ten, I would rate this solution at nine and advise others to go for it.

We are using Microsoft Azure DevOps for the repository for Git.

We are migrating to the on-premise version of GitLab. We do not use any advanced tools. We are planning to do more with DevOps and are evaluating other tools to incorporate in our process of development.

We use the functionality of Git for our development. We do not use the other tools that are integrated into the DevOps. We use it because we have an enterprise agreement with Microsoft.

Microsoft Azure DevOps integrates well with other components, such as Synapse, which is a data warehouse tool of Azure. It is a framework platform for BI and integrated with other tools, such as Power BI.

I have been using Microsoft Azure DevOps for approximately three years.

The solution is stable.

There are other solutions available that are open source and free, such as GitLab.

We are switching from Microsoft Azure DevOps to GitLab because we have the infrastructure and we are migrating part of our service to on-premise which includes our VMs. We decided to install GitLab because it is open-source, free, we can install it in-house, and we have some members that have experience with that product. We are now starting to migrate some projects.

I would recommend this solution to companies that use the incorporated services provided, it is very good to adapt as a DevOps tool.

I have not used the solution extensively enough to give the solution a higher rating.

I rate Microsoft Azure DevOps an eight out of ten.

We are using it for feature delivery.

Before we started using Microsoft Azure DevOps, we didn't really have a mechanism for tracking delivery against a feature or feature delivery. It has really helped us in visualizing what we need to deliver and get consensus across cross-functional teams that it is the right thing to deliver.

It allows us to prioritize an organization-wide backlog, which has really reduced our delivery time for complex projects. In fact, we are in the middle of a transformation program. We managed to kick off the program in a month and start the delivery cycle within six weeks of conception. Before adopting this tool, it would have taken us three to six months.

It is a really easy way to define all of the features that you need to deliver. You can link those features to epics and break them down into user stories. You can also assign the user stories into sprints for doing your product improvement planning.

It is a really simple tool for prioritizing a backlog, assigning that backlog into sprints, and then tracking the delivery by using sprint capacity, points of time, the velocity of the sprint, etc. It is really useful for agile delivery.

There are a couple of things. The tool has a logical link between epic feature, user story, and task, but when you try to generate a report to show the delivery progress against a feature, it is not easy. To see the percentage completion for a feature or progress of any delivery, it is not easy to draw a report. 

It doesn't give you a high-level view of your roadmap for planning a roadmap for delivery and identifying how far you are on that delivery path. There should be the ability to create a product roadmap and then based on the delivery of the user stories, link to the features against that product. We should be able to roll up a view to see how have we progressed against our targets.

When you're accessing it via the web, it works nicely, but it doesn't work for a while if you're trying to access the board via a tablet or mobile device. A lot of the time, we just want to quickly update a task or check a delivery against a sprint by using an iPad or phone. It is not really user-friendly on those devices. It works very well on the laptop but not on other devices.

I have been using this solution for 18 months.

We've had very few issues with Azure DevOps.

There were no issues.

We also use Sparx Systems Enterprise Architect. For business process modeling where you are linking different objects in the modeling domains, Sparx is the most appropriate tool. You cannot model business processes in Azure DevOps.

Azure DevOps is more appropriate as a delivery tool for building out the feature roadmap and defining user stories, tasks, features, etc. It is well suited for taking the data and building it into a delivery pipeline. These two tools don't speak well together. A solution was developed to integrate these two, but it doesn't work very well.

It was super simple. We just needed a username and a password. The board was pre-setup by our administrator. In fact, we didn't even have to go through any real training, even though the training was available. It is really intuitive to use.

Its pricing is reasonable for the number of features that you get and the functionality that you can utilize for the agile delivery, which is what we are using it for. I found it extremely cost-effective.

I would rate Microsoft Azure DevOps an eight out of 10. It is the primary tool that we've been using. It works very well.

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.

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.

I have been using this solution for about nine years.

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.

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.

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.

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.  

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.

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.

We are using it for the source-code repository, automated bill process, very limited automated testing, and tracking trouble tickets or feature requests. We are using its latest version.

The automated bill feature is most valuable. As with most software developers, I can build code on my machine, but if one of my coworkers can't build the same code on theirs, there are always issues in trying to track it down. The automated bill process makes it a lot easier to track down where the issues are and find out what bugs aren't being included for whatever reason.

They should expand it from just a PC, software, or server development platform to other kinds of software or engineering systems so that it is not necessarily built around a normal PC with a server.

I would like to see the ability to write my own scripts in my own compiled program or online. Right now, there are things that you can do in the user interface, but you can't do them programmatically and vice versa. I want to see them both. If I can do it in a script, I should be able to do it from the user interface, and if I can do it in the user interface, I should be able to do it in a script.

I have been using this solution for a total of four years.

From what we've used it for so far, I have not seen any problems.

We're using perhaps 10% of what it is capable of doing. It is far more capable than what we are using right now. With further experimentation and training, I'll probably go from 10% utilization of its capabilities to about 50% or 60% in the next couple of months. We'll never use 100% of what it is capable of doing, but it should handle 95% of everything we need to do. We can always write our own plugins to handle the side things that we need.

Scalability is not really applicable with the code that we write, but the build times and things like that typically take under 15 seconds before we get our responses back. So, it works extremely well.

In terms of the number of users, there are six of us who are software developers. Some of the managers might also partially use the reporting capabilities.

I haven't called them up.

I've used JIRA and a number of different systems going back almost 20 years. We were doing our development using Microsoft tools, and it just made sense to use what they integrate with. Azure DevOps is the perfect environment because we're using Microsoft technology for other stuff. It is always going to have slight favoritism towards the other Microsoft tools.

The basic setup works very quickly, but there are so many things and options.

We did it ourselves, which is one of the problems. We don't know what we're doing.

I don't know what we pay, but I do know what I've seen online. If we switched to JIRA, we will basically have to double our costs because we still have to pay for the DevOps licensing. We're probably spending $100 a month on it. It has only standard licensing fees.

It is a really complicated product. All DevOps stuff is complicated. The advice that I would give to anybody doing DevOps is to have a goal in mind of what you want to do. Then the product will do what you wanted it to do. 

I would rate Microsoft Azure DevOps a four out of ten because I don't know it enough to rate it.