Microsoft Azure DevOps Reviews

We use it for automating our code builds, significantly enhancing collaboration, and accelerating our release cycles. By reducing release times, we're able to ship our product faster, thereby increasing productivity and efficiency.

We use continuous integration and continuous deployment through Azure DevOps. With CI, we gain the advantage of fully approved code merges, as demonstrated in your demo. This ensures clarity on which releases are destined for production. With continuous delivery, we seamlessly deploy to both our test and production servers.

Azure DevOps supports our agile project management and sprint planning processes. This enables us to release sets of features more efficiently and quickly within the Agile framework. Additionally, DevOps facilitates the approval of features, further streamlining our release process.

When using the Agile template, we have visibility into what tasks are available, in progress, upcoming, and completed. This comprehensive view allows higher management to easily track the current status of tasks, including which ones are being worked on and which are finished.

It significantly enhances the testing phase of our software development lifecycle. Previously, after development, we deployed our software to a common QA environment for testing. However, now with Azure Test Plans, we can create isolated environments for each solution using virtual machines. This isolation helps us identify and address issues specific to our product, without being hindered by environment-related issues. With continuous integration through CI/CD pipelines, once our build is completed and approved, it automatically deploys without manual intervention, streamlining the process further.

Since adopting Azure Pipelines, we have observed significant improvements in our release management process. Previously, the process involved various stages and multiple approval steps, leading to fragmentation. However, with Azure DevOps, the entire process is streamlined, allowing for seamless transitions from board check-in to release approval within the same solution.

Before using Azure DevOps, we couldn't release as swiftly as we can now. With Azure DevOps, our ability to release has significantly improved. This increased efficiency means we can release more versions of our product, leading to higher productivity and the shipment of more artifacts than before.

The features that have a significant impact on us include CI/CD, where we have full integration with the source code repository and Azure Pipelines. This enables us to efficiently review and approve source code for deployment and testing. Utilizing Azure Test Plans, we can deploy to virtual machines, facilitating streamlined processes in a dedicated environment.

At times, our development work encounters issues, particularly when executing numerous CI/CD processes. Occasionally, these processes may experience delays or errors, often stemming from unavailable features or functionality in the cloud environment. Improvement in this area is necessary for smoother and more reliable operations.

We have been using it for two years.

This solution is stable. However, as mentioned earlier, configuring multiple CI/CD pipelines, with numerous processes running concurrently, can occasionally lead to issues.

Being cloud-based, this product is highly scalable, offering the flexibility to scale horizontally or vertically as needed. With a relatively small team of ten to twenty users, the scalability of the product aligns well with our requirements. It is widely utilized by both developers and the QA team.

The initial setup varies depending on the complexity of the workload. Some cases are intricate and require significant time to develop the end product or work item. Conversely, there are simpler, smaller cases that can be completed quickly.

For deployment, assistance from Microsoft or a system integrator is essential. Customizing templates and processes requires their full support to tailor them to our specific requirements. Since it's a cloud-based solution, the need for managers is minimized as management becomes simpler. A team of two to three individuals is sufficient for configuring it effortlessly.

The licensing for this product is on a monthly basis. It is relatively inexpensive compared to other solutions that necessitate servers and physical hardware.

 Overall It offers a comprehensive array of features with accessibility and support for customizations and performance enhancements. Its extensive feature set covers various aspects, making it highly versatile. I strongly recommend Azure's demo for exploring CI/CD pipelines, boards, and customization options. It will undoubtedly streamline development activities, reducing effort and boosting productivity significantly. Overall, I would rate it eight out of ten.

We use Azure DevOps for the entire lifecycle of software development, starting with requirements analysis. After that, we use it to continue the process of development and deployment.

Azure DevOps is user-friendly. The UI and the UX are perfect. Their software covers the whole development cycle, from requirements analysis to deployment. In particular, it's helpful in the requirements analysis phase. You can apply your methodology or Agile framework from the beginning. After choosing the framework, like Agile or Scrum, Azure DevOps provides many features, like user stories, tasks, managing boards, and those kinds of things.

Azure DevOps is complete and meets all of your expectations. You can develop your own plugins to customize it however you want, so it's highly flexible. We develop personalized plugins or use ones that other programmers create for the Azure Marketplace. 

This makes up for any possible deficiency in Azure DevOps features. If you want some capability that Azure DevOps doesn't provide, you can develop your plugin or customize any part of it. The options for customization make it worthwhile for any software development.

Microsoft could focus on refining the reporting and dashboard elements of Azure DevOps to improve it.

I've been working with DevOps for about five years.

DevOps is totally stable. And if there are any problems, Microsoft patches them as soon as possible.

When you enter into Microsoft ecosystem, you can scale any part of the product in this ecosystem. For example, you can connect Azure DevOps to Microsoft SharePoint for knowledge or document management. You can connect Azure DevOps to OneDrive for storage. You can connect it with Skype for chatting or Outlook. 

We don't use support from Microsoft. We mostly solve problems by searching for solutions on sites like GitHub and that kind of thing. 

I've used Atlassian products like Jira, Confluence, and HipChat, but I prefer Azure DevOps and the Microsoft ecosystem.

It is effortless to set up DevOps. All Microsoft products are user-friendly and easy to install. If you run into any obstacles, you can use Microsoft library or MSDN for any further help that you need. Microsoft provides a lot of wizards that you can use to solve your problem.

Our primary use case of Azure is to host our web application. We used Azure SQL databases for our project and found it useful to host our web application and make use of all Azure's facilities, such as function apps, API management services, etc. This solution is cloud deployed. 

Some of the most valuable features are the ease of use and the ability to monitor a lot of things. It has a lot of applications and facilities that meet all the developers' requirements. For example, we can use application insights to get an idea of our application's performance. Since it's cloud-based, it's really good for collaboration and working as a team. 

I can't think of anything I would like to improve, since I don't have complete knowledge of the platform yet. I'm sure that as I gain more experience, I will understand it better. The price could maybe be cheaper, but I'm sure I'll have more ideas as to improvements and additional features once I've used it more. 

I have been using this solution for about two months. 

This solution is stable. From what I have used it for, it has been pretty efficient. 

This solution is scalable. Most of my team uses Azure DevOps and other Azure facilities, so there are quite a lot of users. 

I haven't felt the need to contact support. I'm not sure if any of my friends or colleagues have, but one thing about Microsoft is the documentation is extremely good. So we barely falter anywhere because if we thoroughly follow the documentation, it's pretty easy to follow the process through. 

The installation is straightforward since it's cloud-based. You can do it yourself. For deployment, we were a team of about 20 people. 

We implemented through an in-house team. 

This product could maybe be cheaper. My organization handled licensing, so I'm not aware of which subscription they have. 

I rate this product an eight-and-a-half or nine out of ten. I have partial knowledge about it, since I haven't really explored everything in proper elaborate detail, but I would definitely recommend Microsoft Azure DevOps to others considering implementation. 

We are a team of 12 consultants specializing in this solution. We have customers with approximately 200 users each, and we have been able to reduce our customers' deployment time by using Azure DevOps or TFS.

Additionally, our customers have been able to measure and improve their development process, by generating some KPI's as 'average defect fixing time', 'effort deviation', and 'velocity' among others, due to the continuous use of Azure DevOps.

The integration of the whole cycle is the main strength of the tool. If I want to control the cycle with other tools on the market, I would have to use several tools. However, this is not the case with Azure DevOps or TFS.

The ability to extend work items was more flexible than it is now. Talking version control, one of our customers had some issues because they found it very difficult to manage more than 1000 repositories for one team project.

Additionally, I would like to see more powerful dashboards that could be used instead of Power BI. Azure DevOps or TFS does not support graphics from hierarchy queries. It would be powerful to have because some customers don't have Power BI licenses.

We have been working with Azure DevOps or TFS for the past 11 years.

It is totally stable.

The documentation is good and thus, we have not had to contact technical support very often. However, when we have escalated an issue to technical support, they have been good.

The initial setup can be straightforward if the consultant is knowledgeable.

The pricing is very competitive because of the whole development cycle by Azure DevOps. You don't have to buy and integrate several different tools.

Azure DevOps or TFS is a very good tool for development teams. It's easy to use. However, you would need the help of a consultant who has a lot of experience with the tool. This is because the tool let's you do things in many ways, but not all of them will be the right way to do it. It would be better to invest in the services of an experienced consultant.

Overall, I would rate TFS or Azure DevOps at nine out of ten.

There are many valuable features including dashboards, sprints, queries, pipelines, artifacts, and the cover repository.

I would like to see improvement in the metrics and the dependencies. I would also like to see the option to define the dependencies within all teams in the same project. We have a team level, a program level, and a portfolio level. For the metrics portion, I would like to see some drag-and-drop features for the dashboards that would make it possible to aggregate data from the different teams.

The plugin for the iteration walls can also use improvement as it does not work well.

I have been using the solution for three years.

It is stable. Whenever there has been an issue the solution slowed down but there was never any data loss.

The solution appears to be scalable.

I am not familiar with the initial setup.

The implementation was done in-house.

The cost is reasonable. For the basic license, it is around five euros per month. 

I rate the solution nine out of ten.

If someone is considering developing and deploying the infrastructure in this solution, then using this tool is perfect because it's fully integrated with the pipelines and with a server core repository. When you are building infrastructure, then you are able to use the same tool to deploy the server, deploy infrastructure, and all within a few minutes. This gives you access to the same tool, task management, dashboards, pipelines, and the server core repository. So everything you need to develop a server is integrated into the same tool.

We use Microsoft Azure DevOps for CICD, and to organize it in order to visualize the ongoing work.

It allows you to save time while also providing a governance visualization of ongoing activities and transparency.

The most valuable feature of this solution is that it saves time.

The price could be reduced. It is expensive, especially when it comes to infrastructure.

The integration could be better. Being more technology-agnostic through ease of integration would be beneficial. Once you start working for Microsoft, you are frequently tied to Microsoft.

I have been using Microsoft Azure DevOps for the last ten years.

Microsoft Azure DevOps is a stable solution.

Microsoft Azure DevOps is scalable.

I would say the technical support is fine, but I have not had any trouble with the solution.

I have some experience using Jira.

It is very expensive in comparison to others.

As the cost structure is per user, I would recommend paying the cost structure based on the amount of data you use rather than the number of users.

I have recently researched Jira, Microsoft DevOps, TFS, and Micro Focus.

Mostly, because of the pricing, I would rate Microsoft Azure DevOps a seven out of ten.

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 it for the source-code repository, automated bill process, very limited automated testing, and tracking trouble tickets or feature requests. We are using its latest version.

The automated bill feature is most valuable. As with most software developers, I can build code on my machine, but if one of my coworkers can't build the same code on theirs, there are always issues in trying to track it down. The automated bill process makes it a lot easier to track down where the issues are and find out what bugs aren't being included for whatever reason.

They should expand it from just a PC, software, or server development platform to other kinds of software or engineering systems so that it is not necessarily built around a normal PC with a server.

I would like to see the ability to write my own scripts in my own compiled program or online. Right now, there are things that you can do in the user interface, but you can't do them programmatically and vice versa. I want to see them both. If I can do it in a script, I should be able to do it from the user interface, and if I can do it in the user interface, I should be able to do it in a script.

I have been using this solution for a total of four years.

From what we've used it for so far, I have not seen any problems.

We're using perhaps 10% of what it is capable of doing. It is far more capable than what we are using right now. With further experimentation and training, I'll probably go from 10% utilization of its capabilities to about 50% or 60% in the next couple of months. We'll never use 100% of what it is capable of doing, but it should handle 95% of everything we need to do. We can always write our own plugins to handle the side things that we need.

Scalability is not really applicable with the code that we write, but the build times and things like that typically take under 15 seconds before we get our responses back. So, it works extremely well.

In terms of the number of users, there are six of us who are software developers. Some of the managers might also partially use the reporting capabilities.

I haven't called them up.

I've used JIRA and a number of different systems going back almost 20 years. We were doing our development using Microsoft tools, and it just made sense to use what they integrate with. Azure DevOps is the perfect environment because we're using Microsoft technology for other stuff. It is always going to have slight favoritism towards the other Microsoft tools.

The basic setup works very quickly, but there are so many things and options.

We did it ourselves, which is one of the problems. We don't know what we're doing.

I don't know what we pay, but I do know what I've seen online. If we switched to JIRA, we will basically have to double our costs because we still have to pay for the DevOps licensing. We're probably spending $100 a month on it. It has only standard licensing fees.

It is a really complicated product. All DevOps stuff is complicated. The advice that I would give to anybody doing DevOps is to have a goal in mind of what you want to do. Then the product will do what you wanted it to do. 

I would rate Microsoft Azure DevOps a four out of ten because I don't know it enough to rate it.