Microsoft Azure DevOps Reviews

We have a number of use cases. One of them is development, which includes several development teams that use source code control and testing support, as well as the entire software development toolset. I only use the front end, which is the project task management part.

I don't have any metrics on that. I can only give you anecdotal evidence. 

One of the benefits of using a Kanban board is that it keeps track of how long tasks take. People would hold onto tasks for three or four weeks before we started using the Kanban board. However, once we began using the Kanban board, it became more visible. 

We also realized that we needed to divide the tasks into smaller sections, and the tasks lasted an average of a week. As a result, the throughput and velocity increased simply because the Kanban board made them more visible.

I found the Kanban board to be the most useful for my needs.

I'm a project manager. I've been working with non-technical teams and training them on agile methodologies. Using a Kanban board is usually the most straightforward way to get a non-technical team started with an online task tracking tool.

In comparison to JIRA, I believe DevOps has very poor reporting and metrics support. They've done very little work, and they could benefit greatly from improved reporting and metrics.

Essentially, I would like to see more reporting support.

This solution was already in place when I started. I'm not sure when it was first put in place.

I started with the company in May of 2018, and have been using Microsoft Azure DevOps ever since.

We are using the most recent version.

Microsoft Azure DevOps is a stable solution.

It is difficult to customize DevOps. It's similar to a product that has had features added to it rather than being completely redesigned. As a result, it has limitations in terms of scalability and customization.

The most successful users are software developers and technical software managers.

I believe it is quite minimal. Microsoft, in my opinion, does not provide adequate support. My solutions are mostly found online. 

With JIRA, you could call someone, and they had a large community of users who could answer your questions. They also had a support department that provided assistance. Microsoft has a lot of information online, but you have to find it, look around its various websites. It is not well supported.

I used to work as an engineering manager, a scrum master, and as part of a technical team. JIRA is my preferred tool for this. 

JIRA is a more robust and mature tool. However, as you are aware, JIRA is more modular and requires integration with other parts. DevOps, on the other hand, has everything in one, it combines source code control, release management, and task tracking.

The initial setup is fairly straightforward. It's one of its advantages over JIRA. It is easier to set up because it is a simple product, whereas JIRA is more complex, more mature and complete, and more difficult to set up.

We have two or three technicians who deploy and maintain this solution.

You would really have to do a comparison, and you would need some training. 

It really depends on your project management and reporting requirements. DevOps is simple to use, but it is severely limited in terms of project management. JIRA is complete, but it's a lot more complicated.

I only use it for project management and the tools associated with project management. I know it's popular among those who use it for source code control and release management. It appears to be more satisfactory for that purpose.

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

The purpose is for development and testing from the vendor side. Our company works as a vendor, client, and implementation partner. The vendor provides the product, and we make sure that it's implemented correctly for the client. The vendor uses it for the development and tracking of the requirement and the test cases, executions, and building storage.

My access to these tools is very limited because the DevOps pipeline and DevOps is mainly used by the engineering team of development, but the QA is also part of it. Once those people are established, then we are the extended hands or extended part of that for usage. Once they have the stories and features, they start the test cases and link on it. From that point, we just take it forward and once they have a code pull, then we would pull it and build it and deploy it into some QA enrollment.

There are around 20 people using DevOps in my company.

The best tool would be Azure DevOps. There are other tools with AWS and Google, but since Microsoft has solutions for everything, it's easier because it's all their tools. We may be using different tools in order to achieve all those things because they may not have an operating system or a pipeline, so maybe we are using some of the bill tools. In order to achieve DevOps, you may be using a set of different tools and connecting it. In Microsoft Azure DevOps, you have a one shop to get everything.

There isn't a requirement traceability matrix format. In ALM, we have a centralized repository of all the requirements in one place. But in DevOps, it works like a product requirement. In ALM we have the centralized repository of requirements where you can go and see the requirement coverage and discovery and so forth. But in DevOps, it has stories and test cases. Once that project is over, nobody is going back into that requirement. It's a good tool for development activity, tracking and getting all those metrics. If they can build up a requirement traceability matrix, then it would be great.

I haven't seen any issues with stability.

The scalability of DevOps is good.

We haven't had any issues with technical support. Whatever issues we've had, they were solved.

I didn't see any complexity in the setup because everything is from Microsoft. The development tools and operation tools are coming from one shop, Microsoft, so it's easy to connect, plug in, and establish all those things. For Google Cloud or AWS, it's different because they use different tools in order to achieve what Microsoft is trying to achieve. For example, the CI/CD Pipeline.

Even in ALM or in the DevOps tool, it's initially a one-time setup.

I don't know the pricing of DevOps. It would be much cheaper than ALM because ALM came out as a software product initially. Now they are moving into a cloud and subscription model. In that case, Microsoft is coming from Azure and the cloud and DevOps and software as a service, so it would be much cheaper, but the catch would be that they are trying to get money on all sides, like an operating system, Microsoft Office, or Microsoft Azure DevOps. 

The good part is that it's a complete package, but at the same time, once you've gone with them, you don't have much leverage to split out into some other activities because everything is interconnected and entwined by that time, and it would be like a monopoly. It won't be good if you try to split out at a later point in time because everything is connected—all our Microsoft products like operating systems, OfficeSuite, MS Teams, Azure DevOps, etc.

I would rate this solution 9 out of 10.

Our primary use case of Azure is to host our web application. We used Azure SQL databases for our project and found it useful to host our web application and make use of all Azure's facilities, such as function apps, API management services, etc. This solution is cloud deployed. 

Some of the most valuable features are the ease of use and the ability to monitor a lot of things. It has a lot of applications and facilities that meet all the developers' requirements. For example, we can use application insights to get an idea of our application's performance. Since it's cloud-based, it's really good for collaboration and working as a team. 

I can't think of anything I would like to improve, since I don't have complete knowledge of the platform yet. I'm sure that as I gain more experience, I will understand it better. The price could maybe be cheaper, but I'm sure I'll have more ideas as to improvements and additional features once I've used it more. 

I have been using this solution for about two months. 

This solution is stable. From what I have used it for, it has been pretty efficient. 

This solution is scalable. Most of my team uses Azure DevOps and other Azure facilities, so there are quite a lot of users. 

I haven't felt the need to contact support. I'm not sure if any of my friends or colleagues have, but one thing about Microsoft is the documentation is extremely good. So we barely falter anywhere because if we thoroughly follow the documentation, it's pretty easy to follow the process through. 

The installation is straightforward since it's cloud-based. You can do it yourself. For deployment, we were a team of about 20 people. 

We implemented through an in-house team. 

This product could maybe be cheaper. My organization handled licensing, so I'm not aware of which subscription they have. 

I rate this product an eight-and-a-half or nine out of ten. I have partial knowledge about it, since I haven't really explored everything in proper elaborate detail, but I would definitely recommend Microsoft Azure DevOps to others considering implementation. 

I do not recall which version we are using. 

The solution is good for everything, including end-to-end planning and its deployment and testing. 

I like that the solution is stable and that all ends of the process are integrated seamlessly into the tool. These are the solution's greatest strengths. 

The solution should have fewer updates. We need the updates for July. Microsoft tools are sometimes too feature heavy and offer more features than the person actually needs to use. This is why I did not rate it as a ten out ten. 

While the installation did seem to be pretty straightforward, I believe it took awhile, even though I am not aware of the specifics involved. We initially found ourselves struggling with this process.

I have been using Microsoft Azure DevOps for around two years. 

The solution is very stable. 

The solution is very scalable. 

I feel the technical support to be fine. We have not encountered any issues in this regard. 

Prior to Microsoft Azure DevOps, we were using Jira and, before this, KFS. 

While the installation did seem to be pretty straightforward, I believe it took awhile, even though I am not aware of the specifics involved. We struggled with this initially.

The installation was undertaken by a consultant. 

There was a team of, perhaps, five engineers involved. 

I am not aware of any licensing subscriptions for the solution. 

I would very much recommend the solution to others. 

I don't see the need for more integration with other platforms, as the solution is already pretty well integrated, at least, that is, for our needs. 

I rate Microsoft Azure DevOps as a nine or ten out of ten. 

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.

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. 

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. 

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. 

I've been using this solution for several years. 

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. 

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. 

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.

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. 

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. 

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.