Microsoft Azure DevOps Reviews

The most valuable aspect of the solution is the complete tool orchestration within the DevOps. It's great for operations, monitoring, and building tests for deployment.

I like the user interface. It's excellent.

The solution is easy to implement and easy to use.

We've been using their documentation seamlessly. It's been great.

I love it because we have Microsoft Exchange Office 365 and we have all those reports already in place (especially if you're using quality reporting). We get that as an add-on. It comes within the package, so everything is very compatible. The analytics on offer are also very good.

The solution offers great plugins and has great integration capabilities. It runs on configuration management tools like Ansible and Puppet. The monitoring they have for plugins is also excellent. 

Whatever you might need, they seem to have it.

We're quite happy with the tool right now. We're not really using it too much. We are also just starting on it, to be honest, so what we've needed so far we've found that it offers. There isn't anything missing that I can see. 

One thing I would note is that it's hard to know what is included or not in the product. Especially when you begin to try and compare it to other solutions. When you go to a site like VersionOne, they tell you Azure DevOps doesn't have this or that, and when you go to Microsoft, it says VersionOne doesn't have this or that. They could do a better job of laying out exactly what is on offer so customers know going in exactly what they'll get.

I've been using the solution for three years.

In terms of stability, I would say we have no problem with the solution. We have been using the tool for all of our projects and we have no problems with that aspect. If users use virtual missions when they run the testing, everything is even easier.

Scalability, at least for the time that we have been using the solution, hasn't been a problem. We are able to adjust and expand any time of VMs. Any organization that needs to grow its usage should be able to do so easily.

Currently, 40 people are using the solution for one of the projects we're running. We have whoever you could think of in an agile team on it. Everybody from the business analyst to the product managers, to the testers, to the developers, and even to business end-users are on it.

I'm not sure if our organization plans on expanding its usage in the future.

I've never personally had to contact technical support, and I haven't heard from anyone in my team about any negative results. I'm not sure if I'd be able to evaluate their services at this time.

We previously used Jira, however, we have not switched over completely to Azure DevOps. We now use both.

With manuals, the implementation is much easier. It is quite straightforward.

We are not doing any kind of maintenance on the solution. We don't need to because it's so fast. We are not paying for everything in terms of infrastructure development. 

I'm not sure about the pricing. It's not an aspect of the solution I currently deal with.

We're currently looking at VersionOne and CollabNet just to see how they compare to what we currently use, which includes Microsoft Azure DevOps.

I'm new to this company. I've been here only for a year. The previous company, I was using Agile Central, which I really liked because of the user interface. Central was previously called Rally. However, after coming to this company, as they have Jira, I've been using Jira and also, for this one project, Microsoft Azure DevOps. I need to begin considering what I should do at an enterprise level. I'm looking at a variety of options including Microsoft DevOps, VersionOne, CollabNet, and a few more. 

Since we have Microsoft Azure DevOps already in place, I would like something that's similar and competitive. 

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

I personally just love using Microsoft DevOps. I would recommend the solution to anyone. Organizations considering the solution should just go for it and they should get the complete orchestration.

I'd rate the solution eight out of ten. I don't think that I have explored everything extensively yet. Any product definitely will have its own gaps, and since I'm not in a position to understand it 100%, I want to play it safe on ranking it at eight.

We use Microsoft Azure DevOps as a code repository, for task and work management, software tests, and documentation.

The most valuable feature of the solution is task management.

The solution could be made faster because it can be a little unnerving to browse through too many pages and press too many buttons.

I have been using Microsoft Azure DevOps for six years.

Microsoft Azure DevOps is a stable solution.

I rate the solution ten out of ten for stability.

Microsoft Azure DevOps is a scalable solution. In my current company, around 30 users are using the solution. In my previous organization, more than 100 users were using Microsoft Azure DevOps.

The solution makes you faster. You can organize your work in an easy and shared way. You can configure different types of access to allow some people just to read and to be able to modify some things. Since the solution gives you all the benefits of Git, you have a commit history.

We have an MPN subscription for Microsoft Azure DevOps, and it's all included.

Microsoft Azure DevOps is deployed on the cloud in our organization. The product supports our agile project management practices very well. We can configure a process, and it would give you some different types of tasks, like the epics feature, user stories, and tasks. We need very little staff for the solution's deployment and maintenance.

For source control, we use Git repositories that are perfectly integrated into our IDE, Visual Studio 2022. Everything is available, and we can create or pull requests from Microsoft Azure DevOps. We can also manage, reject, and accept the requests. I would recommend the solution to other users.

Using Azure Boards for tracking work items and bugs is clear and visually appealing. It's easy to add tasks. In our current configuration, every time I go inside the tasks and go back using the browser, it doesn't redirect me to Azure Boards, even if I am coming from there.

Since the solution is available as Software as a Service (SaaS), you won't need to do any setup, installation management, etc. It's very straightforward, and there is no particular study required. To a certain degree, the solution is configurable and can suit different use cases. It is working very well in terms of Git repositories. Microsoft Azure DevOps is also very accessible.

You can define tasks using Microsoft Azure DevOps and then reference them when you write a commit message or push code. You can open a previous commit in the browser from Visual Studio, and you can use DevOps to compare some files or to check commits done by Visual Studio. So, the solution is perfectly integrated.

Overall, I rate the solution a nine out of ten.

We use the solution mostly for automation, deployment, generating build, and creating virtual machines.

The build and release management features are valuable. The deployment packages are also valuable.

Requirements traceability must be customizable. It is very difficult to integrate the product with third-party tools. It is all proprietary. It's not very customizable. It should be managed better. The product is not sufficient to generate documentation automatically.

I have been using the solution for three to four years.

The tool’s stability is good. I rate the stability a nine out of ten.

We have around 60 users in our organization.

The turnaround time is high.

Positive

My team set up the solution. It took one and a half years to stabilize.

The tool helps us save reasonably.

The solution is expensive.

Overall, I rate the product a seven out of ten.

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.  

I work in a consulting firm responsible for adding, managing, and deploying government projects. We are using Microsoft Azure DevOps in one of the projects for backlog management, test planning, test execution, sprint planning, bug fixes, and enhancement requests. We use the solution for anything related to development testing.

The solution's most valuable features are backlog management, build release pipeline, and testing. They're easy, intuitive, and increase productivity. Usually, if you don't use such a solution, you end up using Excel. Then, you won't have shared documents, and there'll be no single source of growth. Everybody will keep a different document somewhere, and you will spend a lot of effort reconciling the latest status.

Using Microsoft Azure DevOps makes it really easy for us. Anytime you can see how many bugs are open, you can directly get it out of the tool. The solution's reporting is really easy. You can create ad hoc reports based on management requirements. If you are sitting in a meeting and somebody asks you the number of chain requests, bugs, or enhancements, you can create quick queries and show them the status. I think this directly affects productivity.

Microsoft Azure DevOps doesn't have an ITSM tool compared to its competitors. We also use Jira for another project, and Jira supports ITSM or ticketing. Since Microsoft Azure DevOps doesn't have this feature, we have to depend on another solution for service request management for support tickets.

The solution should include ITSM tools and security. DevSecOps are third-party security plug-ins that you can integrate with DevOps. Azure DevOps itself doesn't have anything out of the box. Enabling security so that the solution automatically starts checking things would be a really handy feature.

I have been using Microsoft Azure DevOps for three years.

We haven’t faced any issues with the solution’s stability.

I rate the solution a nine or ten out of ten for stability.

Since it's a SaaS solution, we haven't faced any scalability or performance issues, and we haven't struggled when we had a lot of users. We have gone through a curve. We started with around ten users. At the peak of the project, we had almost 50 users. Since we are in maintenance, we have come down to 10 to 15 users.

We use 100% of Microsoft Azure DevOps for our project. Everything is within Azure DevOps. If anybody says that we need to work on a feature, the first thing we do is create a DevOps item. So, we don't do anything outside DevOps.

The tool provides the features, but we haven't been able to onboard end users. We are a consultancy firm that works with system integrators and also engages with the end client. We have been able to onboard the system integrators, and we are also using it.

However, the end users still prefer sending emails and documents. If you send them a link to run a test script, they won't do it. So, the end users still prefer the old ways, such as emails and documents.

I rate the solution's scalability a nine or ten out of ten.

So far, we haven't faced any issues in terms of technical support. There is good documentation available if you are looking for support for configuration. So, you usually end up resolving your issues yourself. Since this tool is widely used, you can find help online. People are writing content about this solution, and Microsoft itself has good documentation.

On a scale from one to ten, where one is difficult and ten is easy, I rate the solution's initial setup a nine out of ten. The solution's initial setup is pretty easy, and the rollout is pretty quick. You can enable it and then keep on modifying and updating it.

It took us less than a week to deploy Azure DevOps. Since we were using a cloud environment, there was no infrastructure requirement. We went on Azure DevOps, created an organization, and then created a project. Inside the project, we selected the type of project.

There are different templates that you can follow, including the CMM-level approach or the basic approach. We selected one of the templates and copied the template. We made some modifications to the template for the project because that template is used for governing steps.

Then, we created depositories, which is pretty quick. In a week's time, we were up and running with backlog management. It took a couple of weeks to complete the automated build and deployment pipelines.

We needed one person to set up the project and one knowledgeable about the build and deployment pipelines. If you have a person who knows how to do the pipelines, you can also configure the project. So, one person is good enough to set up the entire project.

We have seen a return on investment with Microsoft Azure DevOps in terms of productivity because it really helps with the amount of time you need to consolidate reporting and planning. The status is always up to date, and the deployment is very streamlined. You can do the entire thing in Excel, but the overhead would be too much, and you would lose out on things. So, team synchronization and productivity are the return on investment with the solution.

I rate the solution’s return on investment a nine out of ten.

The solution's pricing is pretty cheap. The best part of the Azure DevOps and SaaS model is that there's no upfront cost. The tool has a per-user license. It's free for five users, and there is a price above five users. The solution's deployment and licensing costs are very cheap compared to those of its competitors.

The solution's pricing is not fixed. The solution's testing license is $50 per user. It's $15 for normal users who use backlog management. We have two people from the test team and seven from the other team. This is in maintenance.

Since we had a big testing team, we had 15 people in testing and 30 people in backlog management during peak time. You can say it has a 70:30 ratio. Most of the cost is in testing, and the backlog management is really cheap.

On a scale from one to ten, where one is cheap and ten is expensive, I rate the solution's pricing a three out of ten.

Before choosing Microsoft Azure DevOps, we evaluated other options like Jira and HP ALM. Jira is good at ITSM and backlog management, but it is dependent on third-party tools for pipeline deployment.

It's too complex to do product management with HP ALM. It's a good ITSM tool, but the process it follows for product management is very stringent, which is not very flexible for sprint planning. There is too much overhead in HP ALM to do quick sprints.

We are working with the SaaS (Software as a Service) version of the solution, which is on the cloud. Since Microsoft provides the latest upgrades and patches, it should be the latest version.

We start by creating backlog items. Whenever we get a requirement, we log it into Azure DevOps and plan the backlog. The backlog includes what features we need to develop and what tasks we need to assign to each developer. Each developer is part of the DevOps. Once you have created that backlog, we assign it to different developers based on a sprint.

Suppose we are going to run a four-week development cycle. So, we plan the development cycle, pick a few items from the backlog, assign them to that sprint, assign them to the developer, and then manage the execution of that development cycle. Once that's completed, we will transfer it to the test team so they can test it in Azure DevOps.

They have test scripts that are documented in Azure DevOps. They run tests, record videos, and capture screenshots in Azure DevOps. After the test verification, we deploy the solution. In addition to backlog management and product management, we use Azure DevOps for build and release deployment. We don't manually go and build the software.

Our code repository is also part of DevOps. As soon as we check in the new code, Azure DevOps automatically builds the solution and then deploys it in the development environment. Once it's confirmed, the same is deployed to quality and production. We use the solution to do everything end to end, other than ITSM.

Specifically, Azure DevOps is integrated with deployment for us. When we manually deploy a solution, it's prone to errors. We use Azure for website deployment and Azure DevOps for Apple app or Google app deployment.

As soon as the approval is done in Azure DevOps, apps are automatically published. It will publish an app on the Google Play Store, Apple Play Store, and Azure, which we use for web hosting. So, it is integrated with web hosting, Apple Store, and Google Play Store.

The solution does not really need any maintenance. Once you enable the testing solution, you can start creating your test plans and test scripts directly. Every time you do a deployment, you just need to run those test scripts, which is pretty easy. It's more about creating your test script than configuring the tool. Even if I do it in Excel, I need to spend time on that.

The solution's analytics and reporting are pretty easy. We use them very often on an ad hoc basis whenever we discuss and plan what to deploy and what the next steps are. It's pretty easy, and we haven't faced an issue where we weren't able to take out any reports just by doing it on an ad hoc basis. It's pretty easy, and you don't need to write code or anything.

The tool is pretty flexible and easy to use. I suggest starting with the cloud version because you can create your project easily. Since it's free for five users, organizations with budget constraints can start playing with limited users. I would say start with the cloud-based version and start playing with it. Once you get comfortable with it, you can expand it for other projects. The tool serves a wide variety of use cases.

The biggest key trend these days is fast deployments or quick releases. Given how competitive the market has become, you need to keep on adding features to your product. Azure DevOps supports the sprint methodology, which supports fast deployment.

On top of that, it supports automated build release deployment. That was a headache when I started working. Sometimes, you forget a file when deploying in production, and your system will go down. The solution's features support the latest fast or quick deployment trend.

Overall, I rate the solution a seven out of ten.

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.

Azure DevOps is primarily used as a DevOps tool rather than an AI tool. It is used for source code management, setting up repositories and pipelines, and it can handle a range of workflows from the DevOps stack.

The tool helps by being an all-in-one solution where I can store secrets, code, and pipelines. This comprehensive nature has made it valuable and helpful by improving customer productivity and allowing me to perform multiple tasks without needing additional solutions.

Azure DevOps is highly valued for being an all-in-one solution. It offers capabilities like source code management, secret storage, pipeline management, and more, making it comparable to a multitool that does not require integration with other solutions. I appreciate it for its scalability and ability to handle different workflows effectively.

A notable improvement would be adding more notifications. It would benefit from more seminars or events where Microsoft encourages other users to transition to Azure DevOps.

I have been working with Microsoft Azure DevOps for around two years.

The stability of Azure DevOps is rated as stable and simple, with no complexity involved. I have not experienced any outages or downtimes in Azure DevOps.

Azure DevOps is highly scalable and receives a rating of ten out of ten. It can handle various volumes of workflows, which makes it effective for different use cases.

I have not communicated with technical support for Azure DevOps.

Neutral

Azure DevOps does not have a complex setup process. It requires Microsoft Azure for the services used, and the product itself is simple to set up.

The pricing of Azure DevOps is rated at five out of ten. It is mid-range pricing. It is considered to offer good value for money even if setting up an agent separately is required.

Our discussion mentioned Jenkins as a popular CI/CD product.

Azure DevOps is a very powerful tool with almost every feature necessary for DevOps, so it is recommended to other users.

I'd rate the solution eight out of ten.

We are mostly using Microsoft Azure DevOps for the development dashboard and for CI/CD pipelines. We also use it mainly for Git repository management.

We are primarily using Microsoft Azure DevOps for its Git repository management and CI/CD pipelines.

Service monitoring should be improved. This feature is available for Azure DevOps in the cloud but not on-premise. It can be enhanced to be used with on-premise solutions.

I have almost three years of experience working with Microsoft Azure DevOps.

This solution is stable. Its stability rating is eight out of ten.

I have not contacted Microsoft technical support; I rely on the documentation.

Positive

I did not use a different solution before using Microsoft Azure DevOps.

For me, the initial setup experience would be rated a seven out of ten.

The deployment takes only a few minutes. That said, it depends on the size of the artifact. If the artifact size is large, it will take a bit more time. We did not use any third-party services; we handled it in-house.

I have no idea about the pricing of Microsoft Azure DevOps.

I did not evaluate other options. We had to listen, as we were already using the solution.

I recommend Microsoft Azure DevOps. It is user-friendly.

I'd rate the solution eight out of ten.