Microsoft Azure DevOps Reviews

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.

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. 

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.

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.

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

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

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.

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.

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.

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.

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.

We are using the tools in this solution mostly for planning our software projects by implementing Scrum. We use repositories, and create timelines for continuous deployments and integrations.

The reports have been most valuable. We have created some dashboards allowing us to be able to check our teams, their progress, and mission plans.

Microsoft Azure DevOps could improve by providing better integration with other tools. It is very easy to integrate with Azure, but when you need to integrate with other solutions, such as Amazon Web Services, is difficult.

I have been using this solution within the past 12 months.

Microsoft Azure DevOps is highly stable.

The support from Microsoft is great, if we need to solve some problems with Azure they are ready to help us. The support has been excellent.

Previously we used Visual Studio but then we changed some of our repositories for our projects to the cloud and now we use Microsoft Azure DevOps.

The solution is easy to install and it took us three months to implement. This includes the support for our teams and for them to come up with their strategy to manage our projects.

My advice to others wanting to implement this solution is they need to think about their inter-process before moving to this kind of solution. In many cases, we start to configure some projects using the tools, but if we do not have our roadmap and do not define our goals, we cannot take full advantage of the tools. There should be a lot of planning before moving to the projects.

I rate Microsoft Azure DevOps a nine out of ten.

We use Microsoft Azure DevOps to maintain our project. We create a project in a good DevOps, and then we add the backlog items. The product owner adds the backlog items, and then the development team. The repository is also built into that. We have a private Git report for the project. Under reports, we can create a repository for the big projects and maintain the source code. 

Developers can commit and make a full request. For example, configure Jenkins, reconfigure Jenkins with the repository credentials, and then use it for linking. We don't use the pipeline available to us, and we use Jenkins for CSC.

In our organization, Microsoft Azure DevOps helps senior leadership go in and check the project status and how much effort has been put in by the development team. They can also pick, choose, and add features to be used by the development team. It's like a backlog management tool that helps improve and support projects. 

It's very user-friendly, and the documentation is good. The most valuable feature is backlog item creation, where we pick features and other things. The burndown chart created for projects to be maintained by the development teams is also useful. 

Integration and plugins for other tools could better. Like if you want to integrate the DevOps with other tools that are in the market. This could be for the engineering tools to check code quality, application security tools, and DevOps dashboard tools. 

They could also make the implementation easier. The test plan also has basic features that are not user-friendly. It should also have integrations with test automation tools. We need a test plan, automation testing, and EA-based testing.

We have been using Microsoft Azure DevOps for more than four years.

We haven't got any issues with the technical support area.

The initial setup is very straightforward. 

Licensing cost per user is approximately $11 to $15. We have about 400 users, but not all are active. We have around 200 to 300 active users.

I would recommend this solution to new users if it's a simple project. If you want JIRA, you'll need to have JIRA software for backlog management. 

On a scale from one to ten, I would give Microsoft Azure DevOps an eight.

We are trying to move our entire DevOps cycle to Azure DevOps. It includes test management, source code control, and some parts of CSED.

It is deployed on the cloud, so we always have its latest version.

Most of the features are very valuable for us, especially the source code control and task management.

The main issue that I have is the connection speed. Sometimes, the response is too slow. I am based in Taiwan, and I am not sure if it is because of broadband or something else.

Its initial configuration is also a little bit difficult.

I have been using this solution for almost one year.

It is stable.

It is scalable. Currently, we have around ten users. We hope to increase its usage.

I didn't have to get in touch with them. I didn't have any technical issues.

We have used Jira and TFS. Microsoft Azure DevOps is very useful in terms of management. We are trained to be the users of the DevOps services, but with Jira and TFS, we also had to manage the server, which we didn't want. We wanted to eliminate this kind of effort and just wanted to publish our own developments without having to manage the server.

It is a cloud solution, so there is no installation. Its initial configuration takes some time and is not very easy. 

I would rate Microsoft Azure DevOps an eight out of ten.

In the first years, we had the solution, we did not use it for all of its models - not for the full life cycle. Now, within the past year or year and a half, we wanted to make the best out of it. We now use all the models and all the development lifecycle.

The product has integrated all the relevant models of task management requirements, source control, back management, test management, et cetera. You have a full ALM suite.

The connection to Git, which was bought by Microsoft, is also good. We use Git as a version control tool. 

Microsoft has good integration with its other products, such as Office, Teams, et cetera. 

The solution has proven itself to be very mature and robust. It's quite stable.

The scalability potential is very good. 

I'm not sure if "missing" is the right phrase, however, I am interested in, with all of these tools, if the connection to requirements management tools like DCRM, DOORS, et cetera, would be possible. That's a weak spot in most of the vendors.

We would like some bidirectional synchronization. It's the requirement if you want to analyze it to software requirements, et cetera. That's something that most of the tools aren't that good at.

I've been using the solution for around three or four years at this point. It's been a while.

The product is mature and robust and quite stable. I haven't experienced any problems at all with it. It doesn't crash or freeze. It doesn't seem to have bugs or glitches that affect it. We have the support in-house on servers and we haven't had any problems with defining collections for example.

It is my understanding that the solution is very stable. As an example, our organization has many teams and many departments and we use it across them all the time with no problem. We started using it originally when we had several teams, and now we have tens of teams, and it scaled up to meet our needs and we haven't had any issue with doing so.

We also use Jira. I myself do not use Jira, however, it is used by other teams and colleagues within our organization.

I can't speak to the implementation process, as our IT handled it. I was not a part of the initial setup. I can't speak to if it was complex or straightforward, or how long it took to set up.

We are currently evaluating both Jira and DevOps against each other. We use both in several development units. Lately, I've been looking for some comparisons and reviews, and material regarding those platforms and the comparison between them. I'm wondering to myself whether it's good for our company to have both, or to choose one of them to be the standard platform of our company. That's the main subject that I'm interested in.

We are customers and end-users. We don't have a business relationship with Microsoft.

I'm a manager, and therefore I don't personally use it on a daily basis anymore, however, I manage teams that work directly with the product.

I'd rate the solution at an eight out of ten. If I compare it against other products, it holds its own. It's quite a good solution overall and we've been happy with its capabilities.

I would recommend it to other organizations or companies. I'd advise them, however, to use the source control and to wisely choose which kind of collection they want to set up and configure. It's something very important that will set a company up for success. 

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.

We are exploring this solution. There is not enough protection in the environment at the moment. It's been almost six months since we started the process of exploring the DevOps environment in Microsoft Azure DevOps.

We have a customized development methodology so that it is easily marked to our existing environment. Currently, we required that all these systems blend easily in this one environment. We can actually use all the large frameworks within DevOps properly and automate most of our support, starting from planning through support to deployment.

It has a good GUI, and it's very user-friendly. It is also a familiar environment as we are used to it. All our users are very comfortable working with it. I think the Azure methodology and all those DevOps features in the dashboard are very effective in our environment. 

It's very implementable in our environment compared to the other DevOps environments which we experienced. I won't name them, but this one part of DevOps we have found very easy in our environment because the infrastructure there is fairly supportive and very integrable to the current DevOps environment we use.

The testing environment and different pipelining concepts can be improved. It can also be more user-friendly. They can actually incorporate all those other features, current tools and have those mind maps.

They could add some good analytic features. I think they can be more enriched with some good reporting features. They can also improve the designing tools.

We have been using Microsoft Azure DevOps for about six months. 

Microsoft Azure DevOps is a stable product. I feel it's stable enough for us at the moment. 

The initial setup is not overly complex. It's fairly straightforward. Other than the Java environment variables which lack documentation, it's not complex and easy to follow.

The main agile features are very expensive.

On a scale from one to ten, I would give Microsoft Azure DevOps a seven.

I used Azure DevOps for work item management, sprint planning, source code repository, continuous integration, continuous build, and continuous release. I build whole chains.

The most valuable feature is that it's fully integrated, where we have a single place to do everything that we need.

Testing is really good, it has come a long way.

It is the single source of proof or the single system of record that does everything you need, you don't have to put the different pieces together to form the whole chain.

We can do everything in one single platform, which is why it does a good job.

Requirements management is an area that can be improved.

Integration with Microsoft teams would be a good idea.

I have been using Microsoft Azure DevOps for five years.

It's stable. It's been pretty good, especially in the last two years.

There are no issues with scalability. We have approximately 50 people in our organization who are using it.

We have contacted technical support and they are excellent. I would rate them a nine out of ten.

I am using a mismatch of tools from HP and Atlassian, but they did not give us an integrated toolchain. Microsoft Azure does it exceptionally well.

It is reasonably straightforward, but it is only as straightforward as the problems that you are trying to solve.

If you are trying to set up the whole chain, then the problem is complex, and the solution has to be as equally complex.

The price is reasonable, but of course, you can find others that are cheaper such as Atlassian. But, if you look at the more serious products like Polarion, it's very competitive. 

If you have good Microsoft programs, it's nearly free.

I would certainly recommend this product.

There are a lot of parts to the toolchain for DevOps, so take each area at a time. My advice is to take one step at a time, don't overdo it, and over time build out all of the capacity difficulties. Automation is also one of the biggest things.

Overall, it seems like a really good solution.

I would rate it a ten out of ten.

It is used for development and life cycle management within the company. We use the SaaS version. It is called Azure DevOps services.

It has absolutely improved the way our organization functions from a development lifecycle point of view. It has enabled teams to be more Agile and flexible.

All features are good. Pipelines module is comprehensive, Boards and Artifacts modules are also really extensive.

It is really good at what it does. It is very comprehensive, and it has some really great aspects to it. It has a easy to use UI. It is probably one of the easiest to use DevOps tools in the industry, and it is well integrated.

The administrative capabilities of the tool need a huge improvement. Its Wiki and Reporting functions also need a lot of improvement. Their support can also be better.

I have been using it ever since it was created in 2012

It is very stable.

It is very scalable because it is on the cloud. We have a very large user base and they're all IT-related. The users are engineers, product managers, and management. It is the entire IT organization.

We use their technical support a lot. We have internal support, but we will also reach out to Microsoft to resolve problems. Their support is very good, but there is always room for improvement. It depends on the subject area. Sometimes, they have people who are not as well versed as others.

We've been pretty much on the Microsoft products. We used to use Team Foundation Server, which was a Microsoft product. Before that, it used to be Visual Source Safe. We also used to be on PVCS, SVN and CVS.

Being a SaaS solution, there is no setup.

It was implemented in-house as we have a high level of in-house expertise in the ALM space.

This area is very different for each and every organization and I would recommend that they research cost and pricing for their situation.

No, we did not evaluate any other options since we are heavily tied to the Microsoft stack. However over time, we have adopted other platforms (Java, Node, Python and others) since Azure DevOps is cross platform compatible with Linux, Windows, iOS and Andriod.

If you're looking for a cross-platform solution that end-to-end does everything in the development life cycle, this would be a very good solution for you. If you're looking for a more siloed product that is specifically focused on one particular area of the lifecycle, this is definitely still an option, but you should also evaluate other options as well (Atlassian, IBM Rational,  MIcro Focus ALM, GitHub etc) for completeness.

I would rate Microsoft Azure DevOps a solid eight out of ten. It is really good at what it does, but it also has some solid areas of improvement that are needed. Once they have addressed those, it could be hard to beat.