Microsoft Azure DevOps Reviews

The plugins are the biggest thing. I like how Visual Studio is designed as a shell application, and then the plugins make it do what you want it to do.

Microsoft could improve Visual Studio by making it easier to find the plugins you need to get your job done. Maybe they could implement an AI search instead of a simple tech search. Sometimes, people come up with a catchy name for something, and you don't know how it's spelled. For example, a developer might come up with a packet wizard and spell weird, like P-A-K-I-T.

I've been working with Microsoft Visual Studio since it first came out in 1997, so about 24 years.

Visual Studio is very stable.

I don't think scale applies to Visual Studio because it's a developer tool. And I haven't had a lot of experience with massive projects where multiple teams are working on the same source code. I've only worked on a team of a few people.

I think support is probably pretty decent, but I've never had to use it. I just look at Visual Studio's source code to troubleshoot it. 

The setup is pretty straightforward. Visual Studio runs pretty fast.

I'd say Visual Studio is a nine out of 10. If you're thinking about adopting Visual Studio, research the kind of functionality you need. The nice thing about Visual Studio Code is that it's a modular design. So if you're working on a strange language that has a different syntax, you can just get a plugin that'll format your code for you based on the language it's in.

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

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

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

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

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

I've been using it for eight years.

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

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

It's very, very stable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The solution is stable.

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

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

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

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

I rate Microsoft Azure DevOps an eight out of ten.

We are using it for feature delivery.

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

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

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

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

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

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

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

I have been using this solution for 18 months.

We've had very few issues with Azure DevOps.

There were no issues.

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

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

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

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

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

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 are a product company, and we use Azure DevOps for product development. It is our backend platform, and we use it for all of our development activities.

You get a complete solution with Azure DevOps. You can do everything in one place, starting from requirement gathering until you release the product. It is a reliable, scalable, and handy product.

Its testing features are limited and can be improved a little more. They should provide more options from the testing and build perspective. Currently, we have to use a third-party product for testing. It would be great if it has more than one testing tool. 

They have brought a lot of new collaboration features in the latest version. We haven't used those features, but they should continue to expand it more on the collaboration front so that two developers can look at the code and work at the same time. It will be helpful for working from home.

Its UI can be easier and more customer-friendly. The UI can be improved from the project management and agile perspective.

Its price can also be reduced. It would be great if they are a little bit more competitive in terms of pricing because many open-source products are currently available in the market.

I have been using DevOps within the last 12 months.

It is definitely a reliable solution. That's why we have been using it for quite some time.

It is scalable. There are no issues in terms of scalability. Currently, we have around 100 users. Its usage will definitely increase because a lot of new projects are coming.

When migrating from TFS to Azure DevOps, we didn't get great support and response from Microsoft.

Its initial setup was a little complex for us. We had been using TFS for quite some time, and migration was a bit difficult for us. We didn't get great support and response from Microsoft. We had limited resources in terms of support, and that's why it took us longer to figure out how to migrate from TFS.

It has an annual subscription. It can be cheaper for partners. Many open-source products are available in the market, and it would be great if they can be a little bit more competitive in terms of pricing. A lot of startups are looking for an open-source, free, or cheap solution. If they can accommodate such requirements, it will be good for the product in the long run.

I would rate Microsoft Azure DevOps an eight 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.