Microsoft Azure DevOps Reviews

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 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.

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.

We are an agile shop. We use it to build our sprints and for our user stories. We have everything aligned in epics and we track all of our requirements and our velocity.

We are still getting used to it and there is a lot that I haven't looked at yet. For me, at this early stage, the most valuable features are the basic functionality. This includes the ability to build and customize sprints.

I like the tracking and that we can monitor our velocity.

It took a bit longer to figure out, but now that we have, it's easy to use.

When converting to DevOps, it was difficult to map.

I have been using Microsoft Azure DevOps since October 2020 when we converted from Jira to DevOps.

It's stable now that it is up and running. It was a steep learning curve, but not the fault of DevOps. We did not put together adequate training.

Others in the company may have scaled this solution. I have not explored this area yet.

I have not contacted technical support.

Previously, we were using Jira. Now that DevOps is running, I find that for what I am doing, does the same things as Jira. The main difference is in naming convention and layout.

I wasn't part of the conversion from Jira to DevOps but it was a painful process. We lost data, things didn't map. My Scrum Master who used it was not happy with the process.

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

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.

We use this solution for continuous integration. It provides us with strategic analysis. We use it to create and deploy virtual machines. In short, we mainly use it for integration and deployment.

Currently, there are five to ten of us working on conception. Soon, there will be more than 200 of us using this solution. 

The most interesting subject for me is the deployment part where you build virtual machines and enable them to learn. That's interesting to me.

As I'm in the very early stages of this story, this is a hard question for me to answer. However, I think that the integration is to some extent, immature.

Overall, so far we have no major issues to report. 

I have been evaluating this solution for roughly six to eight months. 

The initial setup was quite straightforward.

The licensing costs are reasonable. 

We also evaluated GitHub and GitLab. We actually have one deployment that is already ongoing in GitLab. 

Currently, we're evaluating both GitLab and Microsoft. We're trying to get a sense of which one is better for us. 

Overall, I would give this solution a rating of eight out of ten.