Microsoft Azure DevOps Reviews

The key thing I find benefits me is the ability to track right from the feature and determine what has happened. I have a direct link to the test and the metrics that are available.

There are a lot of helpful features available for tracking dependencies.

The dashboard could be improved. Although there is flexibility in configuring it, there are some metrics that we have to configure ourselves. Improving the metrics that are readily available on the dashboard would be very helpful.

I would like to see better integration with third-party solutions, where if they are part of the DevOps pipeline then the reporting could be made available on the dashboard.

Having some form of check modeling integrated into Azure would be useful.

I have been using Azure DevOps for the past four years.

We have had no issues in terms of stability.

The offerings in terms of scalability are good.

We have not had to depend much on Microsoft support for DevOps and project management. However, I can say that the general support that we get for Azure is good.

I have some experience with Jira from Atlassian, although I have worked with Microsoft Team Foundation Server from the beginning.

The initial setup was straightforward. While we were migrating, we had training from Microsoft, which was helpful.

I haven't really looked into other options.

Overall, this is a good product and one that I recommend. The features it has have helped us, especially with tracking dependencies.

I would rate this solution an eight out of ten.

The ability to interact with various other Azure services like for a deployment or using CICD was very helpful because when we leverage it for Azure IT helps. There's no CICD pipeline available. They provided us with some of the plugins to deploy that onto the Azure IOT edge.

They do very frequent releases, there's a complete change in UI kind of stuff. Sometimes it feels like they change it too often. They fix issues and add new features quite regularly which is good. 

They leverage a lot of new features, new features get released frequently, and sometimes the change management on our side is a bit complicated because we'll see something and there's an entirely different way how it is presented. You need to get it all working again.

Previously we asked them for more analytics on top of what they already had so that we could look at it comprehensively and see how the projects are progressing. They implemented these changes for us. 

It's stable. It's good. If there are some features missing we connect with the Microsoft team and then they get it developed and we utilize it.

It is very scalable. We use it for quite a lot of projects including running the data and all that stuff. We do quite a lot of analysis and analytics on top of that.

We have hundreds of users using this solution.

We don't really use technical support for incidents but more for developing new features. 

I've been using Microsoft based solutions, like VST and then like before that DSS. It was a natural progression from VSTS into Azure DevOps.

The initial setup is straightforward. We've been using Microsoft products for a while. 

It's a good tool, quite rich, it has a lot of features, and quite a lot of analytical capabilities which are built on top of it so that you can see how your projects are going and all that stuff. It's a good tool.

I would rate it a nine out of ten.

We produce multiple different software for different markets in different countries. It's really for everything you can possibly think of, from online games to financial systems, to payment gateways, to APIs, to service desks, back-office analysis tools, admin tools, et cetera. We use it for anything and everything really.

The solution is great due to the fact that it's kind of an entire ecosystem. I'd say the work items are probably the most valuable aspect.

The stability has been great.

The solution is scalable. 

The interface is very bad. It's an aspect that really needs to be worked on. It is going to probably get the developers to start abandoning work items.

Our initial setup was quite complex. 

The presence of Microsoft in the country is limited.

I've used the solution since it came on the upgraded from Team Foundation Server - about ten years. We've used it for a very long time. 

The stability has always been really good. There aren't bugs or glitches and it doesn't crash or freeze.

We've found the scalability to be good. We have about 2,000 users on it right now. We haven't had any issues with scaling as needed. 

For us, the initial setup was extremely complex due to the multiple organizations we had on the go. We actually had to abandon our initial rollout and rethink the whole process though. 

I'm in compliance, and therefore cannot speak to what the maintenance process is like for the solution. 

We had a combination of both in-house and vendor help with the setup process. We've got enterprise agreements with Microsoft, so they always give us resources to assist with our deployments. We already had TFS deployed, so it was an upgrade, really.

I don't deal with licensing. I can't speak to how much the solution costs.

I'm just a customer and an end-user.

I'd advise new users to plan very carefully the way that they would like to set up projects. The model that you choose is extremely important and you might have to do a lot of rework if you don't get it right the first time.

I'd rate the solution an eight out of ten. It's Microsoft. It's backed by the mighty, mega Microsoft. You can't get fired for choosing the top product run by a top multinational company. The downside for us here is, in South Africa, there are only two points of presence. For the data, if it's fully hosted, we only have Capetown and Johannesburg. When it comes to back hall speeds for internet, it could be better if we had points of presence in all the major cities, however, I suppose it's too much investment for Microsoft to make.

We primarily use the solution for our internal development and we have some clients that require some consulting around some DevOps functionality.

We use the product for the development process for the repository, for the tracking of the tasks in the boards, and for the pipeline for CINCD.

The test plan is one feature that we are exploring more right now. This is a great feature that we want to deeper into.

We have a solid base. We can do everything with DevOps.

It is possible to add third-party extensions to increase the usability of the product.

The initial setup is very simple. 

We have found the solution to be scalable.

The solution, for the most part, is stable. 

Some things, like project management, tasks, progress, and having work progress views, require us to use some external tools or to create our own internal tools. These are not native to DevOps. It would be ideal if, instead of searching for third-party solutions, they had these feature sets or capabilities included under DevOps. They need to expand the solution's offering.

While I have used the solution for two years, the company has some personnel that have used it for longer. Our development team may have used it for four or five years. 

The product is stable. We had some regional degradations a few months ago, however, it wasn't too much. For the most part, it's reliable and there aren't bugs or glitches. 

The solution is scalable. If we need to expand it we can do so. 

We've never had to contact technical support. I cannot speak to how helpful or responsive they would be, as I've never dealt with them directly. 

The initial setup is very simple and straightforward. It is not difficult or complex. 

We use the online version. We don't have to deploy the tool. We don't have to put in a lot of effort as we already have the pipelines in the TFS. We just move it to Azure DevOps. 

I'm a solution provider. I sell Azure DevOps and I have a client that was looking to analyze some differences between Jira and Azure DevOps. Therefore, I have evaluated Jira a bit for them.

We are both a reseller and a partner of Microsoft.

We always use the latest version of the solution. 

I would recommend this product to other companies and users. If a company or a team doesn't know how to work with Azure DevOps, the advice I would give is to find someone that knows the tool and do a POC first to make sure you understand everything a bit better before diving right in. 

In general, I would rate the solution at an eight out of ten.

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.

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

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

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

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

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

The optimization feature in Microsoft Azure DevOps needs improvement.

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

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

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

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

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

Microsoft Azure DevOps is a scalable solution.

Setting up Microsoft Azure DevOps was easy.

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

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

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

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

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

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

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

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

It is for all the DevOps functions, such as managing the deployment of the code to the production environment. 

It is good for the purpose it is designed for. It is good for maintaining a repository of application code, creating pipelines for deploying the code, building the code, and deploying the code. It can be easily used by developers. There are no issues.

Reporting could be better. We would like to see how many applications are onboarded in DevOps and in which phase they are. We would like to know for how many applications only the repository is done, but we have not yet done the build pipeline or deploy pipeline. Currently, there is no such report. We have to figure it out ourselves. There is no way to check how many applications are completing their build pipelines, how many applications are completing their deploy pipeline, how many are ready to use, and how many pipelines are working.

I have been using this solution for more than two years.

It is stable. It is also good performance-wise. There are no issues.

We have more than 800 developers who are using this solution, and this is only a portion of the company. Across the company, there are many groups, and we have more than 2,00,000 employees. We are using DevOps across many customer projects and environments, and more than 50% of our projects are on DevOps.

Their support is good.

It is a cloud solution, and there is no installation. You just start using it.

We have one or two admins per project for deployment and maintenance.

I would definitely recommend this solution to others. They can go ahead and use it.

I would rate it a seven out of 10.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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