Microsoft Azure DevOps Reviews

Previously, our DevOps operations relied on TFS and Visual Studio systems. However, with the rise of cloud computing, Microsoft introduced Azure DevOps, a comprehensive solution encompassing version control, reporting, requirements management, project management, and automation tools, including testing and release management capabilities. It integrates seamlessly with Azure services, facilitating the development and deployment of applications on the cloud platform. It supports the entire software development lifecycle, from development to deployment. For instance, when developing a project, it assists in the build, test, and release processes, ensuring smooth progression to higher-level environments. 

Additionally, it supports project management activities such as user story management. Its features include repositories for storing code, pipelines for automating processes, and environments for managing deployment configurations. 

The platform has improved our team's productivity in the versioning system within the release management functionality. Each application deployment is assigned its version. When certain features are unavailable or require enhancement in a deployment, Microsoft incorporates these improvements into the subsequent version of the release pipeline. 

They could provide clearer guidance on deployment practices for the product. Currently, two main deployment methods are available: YAML server deployment and release management using pipelines or Terraform. They should offer recommendations on which approach is the best practice for deployment.

We have been using Microsoft Azure DevOps for 5 years.

It is a stable platform. Being a cloud-based solution, it benefits from zone redundancy policies, ensuring continuity even if one server experiences downtime.

We have more than 35 Microsoft Azure DevOps users in our organization.

The initial setup process is easy.

The costs are moderate and justify the value provided. With Azure DevOps, we can easily track your projects, monitor statistics and reports, manage backlogs, and plan deliveries. We can manage larger teams under one platform.

The product documentation contains all the necessary information to get started with the platform and understand its evolving features. Additionally, numerous resources are available on platforms like YouTube, where various vloggers share valuable insights and tutorials on using Azure DevOps effectively.

I rate it an eight.

Being a project manager, it is necessary to create sprint, and kanban boards for management decision-making and our product life cycle. We use the solution for sprint backlog creation and bug reporting for IT department fixation. The dashboard is an interesting feature with visibility on the pending due dates. 

Since using this software, we have revoked the usage of MS Office tools and prefer to instead use Azure.

Azure is one of the few project management software solutions that provide a clear view of project standing, and sprint of product backlog as well. 

As far as my organization is concerned, we use this software for managing the project life cycle where we raise change request forms here and the IT developer provides the solution and from there we can conduct the UAT and sign off for closure. 

The entire product life cycle is being managed with task assignments so broader and a clear understanding of scope is provided by this software and the organization can better understand its current progress.

The available Kanban board is the best feature for management decisions. The sprint capabilities of the product break down the feature and characteristics of the product into steps and if any step is pending we may forward it to the backlog. 

Microsoft Azure is an Agile methodology, so multiple steps can be performed by different user segments in order to achieve the scope smoothly. 

More features can be included. We'd like to see better Kanban templates and an audio-video chat facility. 

The bug reporting facility can be enriched; there is nothing to mark "passed" "failed" the test cases. 

The dashboard can be enriched. 

Related links must be visible on the dashboard for integration purposes. 

I've used the solution for the last two years.

The stability is good.

The scalability is good.

Customer service and support are good. 

Positive

We did not use a different solution previously.

The initial setup is a little bit complex.

We worked with the vendor.

We have witnessed a good return on investment. 

This is good software for a reasonable price.

We did not evaluate other options. 

When I was working at Microsoft, I was one of the core influencers on the feature set and had deployed this solution internally across several organizations. We used it for anything from its CoreALM feature sets to inventory tracking and workflow management and operation support and finance management. There were a bunch of other scenarios. At its core, it is a database with a front end that easily makes it so that you can create new forms and stuff. Then they expose an API, which means you can do a lot of things with it beyond its core use cases.

It becomes a single source of truth for whatever operation is implemented within it. You can have your product definition in there from a requirements management standpoint and then log in bugs and defect management and RPNs and a bunch of other things. You have this single source of truth as they provide an analytics service, and then also easily tie into Power BI. It's really easy to just look at the health and overall operation of your entire business from a single source.

The extensibility of the work item forms and customizations as well as the backend API to query the data, et cetera, and manipulate the data programmatically are all very valuable aspects of the product.

The UI, the user experience, is challenging for newcomers. Once you get it, you get it, and it's not too bad. However, it takes some effort to learn how to work with the system. There's a moderate learning curve. I've used both Jira and Azure DevOps, and I would have that same feedback for both tools.

The biggest challenge has been that both Azure DevOps and Jira tend to pivot more towards software development and the industry is going more towards full end-to-end product development - hardware and software. These platforms could do a lot more to help support the mechanical, electrical, controls, robotics, and more of the hardware side of things.

I started using the solution in 2010. It's been about 12 years. 

I haven't had a problem with stability. There aren't bugs or glitches. It doesn't crash or freeze.

When you surpass a terabyte of data from a work item standpoint, certainly there are some limitations in performance as the running is querying that large data set in the backend.

I've done multiple different deployments. Sometimes, the smaller, smaller deployments have been a handful of five people, and it might be three software devs, a test engineer, a hardware engineer, and a PM. 

I've also done larger deployments where it's 8,300 people. That was a mix of hardware, software, PMs, firmware engineers, front-end, full-stack devs, mechanical engineers, electrical engineers, et cetera. 

In the deployment that was 8,300, it's actually still deployed there and growing. Another deployment I was a part of that was a medium deployment - 20 users - has since reduced more due to politics and going back to the front-end, ease of use. There are some folks that it was too high of friction to use it. You can scale it up or down to match your needs.

I don't deal with technical support in the traditional sense. I know the developers who've developed it, so I just go talk to them.

I've also used Jira.

I previously used SharePoint and Microsoft decided the direction of SharePoint to be less workflow-oriented and less list-oriented and more as a document store. As their roadmap moved away from work management, I've moved over into the TFS/Azure DevOps world.

I was a Microsoft employee. There was some natural tendency to just go with the Microsoft tool, however, it wasn't a hard, fast requirement when we just looked at the feature sets and stuff. 

I've been a developer on the backend. In terms of setting up the product, my answer would be highly complex. If I were just doing it for a core user, set of users, then I would say the setup was relatively frictionless. I would say the one point of ambiguity is for some newcomers if they don't understand the difference between CMMI templates versus Agile, versus Scrum, they'll find it complex. I've seen a lot of new users create dummy projects to then go in and see how each of those is configured from a template standpoint. Work could be done there to just reduce that level of friction.

In terms of deployment times, I've been on multiple different sides of levels of deployment. From the simple side, I've seen deployments take as little as a couple of minutes. If it's teams of five, for example, they go into the web app, they start up a new project, and boom they're in. They get all the requirements and user stories and all that stuff done. 

I've also been on the other side where it's been nine months with 22 people working full-time to configure and deploy this system across thousands and thousands of users. It just depends on the size.

It's hard to put a number on managing the plan of record. I haven't tried to calculate an ROI. It does what it's supposed to and it's more accessible than an Excel sheet.

The solution costs $5 or $10 per user, per month. It's a nominal fee.

I would actually prefer it in that they give you the first five users for free. That little bit of free users goes a long way, just from an initial trial and adoption standpoint. I would encourage them to keep doing things like that.

If you use the other services - if you use their build and compute engines and stuff like that, they charge some amount for computing and some of their extensions. These are not necessarily Microsoft's extensions. They are third-party ones and they'll charge. Depending on if the feature is core to the product, or it's an extension, it might or might not cost you something extra.

I've evaluated pretty much every ALM.

We're just a customer and an end-user.

I've used all the versions, starting back with Server 2005. Now I'm just using their online version.

In terms of advice I'd give to new users, I'd say it goes back to basic change management. Understand who your attractors and detractors are. Lay out the feature sets, ease of use, and things like that. That at least will help detractors become a neutral party as there are always going to be people that create friction within a deployment. Just have an effective change management plan. I've looked at over 12 different ALMs and they all have their pros and cons. It really just comes down to just picking one and going forward with it and learning it.

I would rate the product at an eight out of ten.

Azure DevOps helps us automate building, testing, and deploying our code through CI/CD pipelines.

Valuable features for project management and tracking in Azure DevOps include a portal displaying test results, check-in/check-out activity, and developer/tester productivity. This portal provides options to view development and testing velocity effectively.

I don't see any major need for improvement in Azure DevOps. The only downside is that the deployment could be a little challenging but it is manageable.

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

We have not had any stability issues with the solution.

Azure DevOps is highly scalable and fairly straightforward to scale as needed.

As a Microsoft partner, my clients range from medium to large organizations, with a focus on larger clients. However, I also serve some smaller life insurance companies.

I have received excellent tech support from Microsoft and I would rate them as a ten out of ten.

Positive

I have used Amazon and Micro Focus products in addition to Microsoft offerings, though the majority of my work has been with Microsoft. The main difference is in the documentation and available tech support, where Microsoft excelled with abundant resources compared to Amazon and Micro Focus.

Deploying Azure DevOps pipelines can be complex, but it is straightforward with careful planning and step-by-step execution. Challenges may arise from the multitude of options and design considerations, requiring expertise or guidance from experienced professionals. While there is ample learning material available online, structured examples could enhance usability by providing clearer guidance amidst the vast amount of documentation.

Microsoft's licensing and pricing for Azure DevOps are competitive within the market. While it may be expensive, it is almost the same as the pricing for comparable products in the industry. I would rate the pricing as a six out of ten in terms of costliness.

I prefer Azure DevOps over other solutions. I appreciate its intuitive YAML-based definition language and find its object model and configuration more intuitive than other systems.

We used Azure DevOps to collaborate on migrating a legacy banking application from a mainframe to a Windows platform. The project aimed to demonstrate the feasibility of migrating legacy banking systems.

Azure Repos improves code version control and collaboration by providing a centralized repository for source code. It enables multiple developers to work on the same project, track revision history, and merge code changes efficiently, essential for collaborative development environments.

Using Azure Test Plans significantly improves software quality by enabling structured test planning and automation. This ensures that code is thoroughly tested, enhancing solution integrity and mitigating risks associated with code implementation.

Integrating Azure DevOps with other tools and services is straightforward and intuitive. I found it easy to integrate monitoring and other tools with Azure DevOps.

Before implementing Microsoft Azure DevOps, new users should be aware that it is a complex software requiring careful planning and design. Conduct a proof of concept to ensure it meets your needs, and engage specialists to design your environment accordingly. Additionally, be prepared for a cultural shift in utilizing the tool effectively.

Overall, I would rate Azure DevOps as a nine out of ten. I always recommend it to all of my customers.

We're doing a full continuous integration (CI), continuous delivery (CD), continuous testing (CT), security, delivery, and monitoring.

We're currently using TFS 2013, TFS 2017, Azure DevOps Server 2019 update one, and Azure DevOps services, which is the SaaS cloud platform. I manage all of these.

It is deployed on Azure DevOps Server and Azure Services' private cloud.

They have been lately adding features to the services on a regular basis. Every two weeks, they are adding functionality to Azure DevOps Services to match it with what Azure DevOps Server or on-prem would offer. So, we continue to get more robust functionality.

My favorite right now is that they are starting to open up the API availability within Azure DevOps Services. 

Another thing that I like about Azure DevOps is that you can use it with any of the products that are on the market. You can integrate it with Jenkins and other open-source products to complete that fully functional CI, CD, CT, CM, and CS pipeline. It continues to enhance. 

We are currently in the process of moving all of our on-prem to the cloud platform. We are trying to make that move and host the majority of our DevOps services in the cloud because the cloud is where most of the things are going nowadays. However, the process of this transfer is not straightforward, and it could be a lot easier. Microsoft hasn't provided the maturity for migration tools. It could be a lot easier in that respect.

I want to see them continue to advance the API capabilities. They could add some more robust functionality to the administrative layer within ADO services. There are a lot of configuration elements that you need to take care of at the organization level and the project configuration level from an administrative capacity. When you're dealing with process templates and things of that nature, you have to do them all manually. Being able to automate some of that using scripts or API functionality would be really nice.

I have been using this solution for about nine years.

It has actually been pretty stable. Some of the early gen ones were not so stable. Before Microsoft started communicating with the end-users, they would make changes in the middle of the workday, which was a bit frustrating because things would change, which would impact the end customers because they weren't expecting that change. Microsoft wouldn't communicate with tenant administrators and tenant owners, but now, Microsoft has gotten a lot better about articulating their roadmap and communicating when those kinds of changes are coming down the pipeline. We are now able to communicate that out to our tenants and the end-users working within our projects. There is a lot better communication in that respect, which makes it easier for us to make customers aware of what might be coming, what is going to cause changes for them, what are the timeframes in which those things are going to hit their views, and what to expect from those things and additional functionalities.

For the cloud, it has been really good. For on-prem too, it is easy enough to scale out. TFS also has always been pretty easy to scale out.

In terms of the number of users, currently, we're in a transition because we were just acquired by another company. So, we're leaving our parent company, and we're going to a new company. The numbers that I have are in flux. Our current numbers are at about 600 for just our existing or old company. I've been asked to stop onboarding my users and projects until we move our current organization into our new operational tenant in the new company, but I'm projecting that we'll have between 2,000 to 4,000 people.

I use it all the time. They're very good when you get to the right queue. So, when it is working, it is great. I would rate them a nine and a half out of ten because I always think people have room for improvement, but they've been very good and supportive.

It works great for us especially now because we've kind of been divested from our old company to our new company. When we were with our old company, it was a little bit mired because of the way our enterprise architecture was. My requests didn't go to a North American team. It went to an EU team, and then I had to work within EU hours to get support, whereas I am in North America. That was a little tricky. Our old parent company was parented in the UK, Ireland, and Scotland.

I've used other solutions in tandem, and I have been an administrator for them. For example, I've used Jira and Confluence products, which is Atlassian. I've also used Remedy, but I'm not sure if they're still in the project management. I have also managed HP Performance Center and Tricentis. I've actually been administrating these for the last two years for this company.

I also use UCD, which is another very similar product. It does a lot of the same things and is also agnostic, just like Azure DevOps. You can use both of these with any of the products that are on the market.  

It is pretty straightforward on the administrative side, but I've been working with this technology for a long time. It really falls in line with the majority of Microsoft products. If you're familiar with the Microsoft stack, it follows their pretty standard setup. You go through a similar process. It is just about knowing the nuances that Microsoft has when you're doing a farm configuration or a farm setup and the recommended prerequisites before you get started.

If we're talking about new end-users who are going from an older version of TFS to Azure DevOps Server or Azure DevOps Services, there is going to be a bit of a delta because the technology is different. There is a slight learning curve. Of course, it has got fancier bells and whistles and a jazzier user interface. It has softer edges and things have moved from left to right. Things that you found on the left side have again moved back over to the right side for administrative or usability functions. Your security elements and the things that you used to see on the left side have again switched back to the right side. These are the kinds of nuances about which you would need to educate your end-users. You need to get them used to the boards and how to use those. If your company is transitioning from a CMI model to an Agile model, it is going to be very important for the folks who are administrating your projects and your project managers to know how to configure the projects themselves, how to use Teams, and how to use permissions. Security becomes even more important because a lot of that really influences how you see the information within your project, and how you manage your boards, your sprints, and the work items that you allocate to your scrums or sprint users.

As you're going through different stages of your project, you have your pipelines and repos where your more development-centric users are going to be. I try to allocate out two different kinds of users that we're going to have and target them when I'm educating my folks. You have a kind of power user, and you have your regular contributor user. It is important to make this distinction because there are folks who are going to be doing basic or just regular contributor work. They will just contribute to the work items that are on a board or within a sprint. You're also going to have users who need to be slightly elevated, which is going to be that basic plus test plan. You need to understand how those affect your subscription and billing towards that subscription and how to manage that when they're not actively using it. You need to monitor this and enroll them back to a stakeholder so that you're not constantly incurring costs against your pay-as-you-go subscription costs. Everything is pay-as-you-go once you get into the cloud.

I would ask those who are looking into implementing Microsoft Azure DevOps if they are already on the Microsoft stack of products. If they are, I would highly recommend them to use Azure DevOps Services or Azure DevOps, because they're already paying for that as part of their E-agreement. So, they should take full advantage of that because it is part of their licensing agreements. They should exploit what they're paying for because they are already paying a lot of money for Microsoft products.

Both UCD and ADO are the best products in the current DevOps space right now. They're both agnostic, and you can plug and play and integrate them with the majority of the tools in the market. You can integrate them with Jenkins and other open-source products, and open-source is where everything is going when you move to the cloud. Having that flexibility and viability within your company and business, no matter whether you're a small or large company, is a huge benefit. That will allow you to be flexible and deliver to on-prem or container.

Microsoft is extremely flexible, and they are listening to feedback and hearing what customers are saying. I've worked with Microsoft for almost 20 years now, but I took kind of a two-year sabbatical. Most of that time, I was developing out their SharePoint Online O365 platform. I stepped away for two years and then I transitioned over to DevOps because they really weren't taking feedback that was being provided by customers, and they were ignoring the customer experience, but their new CEO has kind of refocused Microsoft's outlook on the customer experience and is putting the priority back where it needs to be. They're doing a much better job in terms of incorporating feedback. They're continuing to advance and advent their product, and they are keeping ahead of and staying in touch with what technology is doing from a CI/CD pipeline perspective. This is why I am looking forward to continuing to use them.

I would rate Microsoft Azure DevOps a nine out of ten.

As an architect, I use Azure DevOps for our projects, primarily focusing on setting up CI/CD workflows. We track tasks and maintain timesheets on Azure DevOps. I collaborate with project managers to define deployment pipelines and ensure smooth deployment processes. While Azure DevOps serves as our project management tool, my main role involves architecting deployment strategies and working closely with the project management team to implement them effectively.

Switching to Azure DevOps initially posed challenges, but as our team became familiar with it, we found it greatly improved our daily operations and productivity. Its streamlined processes made our development workflow more efficient.

What I like most about Azure DevOps is how easy it is to manage projects and control deployments. Once configured, team members can manage deployments if they have permissions. Additionally, the reports feature helps generate itemized invoices for the services provided to clients, which is valuable for billing purposes.

One potential enhancement in Azure DevOps could be integrating more customizable reporting features, particularly for Power BI integration, to provide better insights into project data.

I have been working with Azure DevOps for five years.

Azure DevOps is quite stable.

Azure DevOps is scalable and can be used in distributed environments and for different tenants.

Before Azure DevOps, we used various tools like Jira. We decided to switch to Azure DevOps to have all services unified in one place, simplifying management. The main advantage is having everything centralized.

The initial setup process for Azure DevOps was somewhat complex, requiring documentation and technical support. Migration from previous tools and configuring project guidelines were involved. The deployment strategy involved creating directories, and repositories, setting up environments, and assigning access rights, following a predefined plan. Initially, deployment took about three to four hours, but now, for regular deployments, it typically takes 30 minutes to an hour, depending on project stability. 

For the initial deployment of Azure DevOps, gathering information from various resources is essential, but typically, only one person is needed to handle deployment through the web interface. Maintenance involves regular tasks like backups and occasional updates, requiring minimal effort.

The pricing for Azure DevOps may be higher compared to other tools, but overall, I find it reasonable.

In my experience, integrating reporting and analytics into Azure DevOps enhances project visibility and decision-making processes. We can easily generate reports online to track project status and task progress. Additionally, I have integrated Azure DevOps with other tools like SQL Server, enabling us to gather data for generating Power BI reports.

The most beneficial integrations with Azure DevOps are integration with other project management tools for seamless collaboration and APIs for importing data into applications. Additionally, integrating with personal models allows for enhanced analytics and reporting on resource performance and other project metrics.

The source control management features of Azure DevOps, particularly Azure Repos, are highly effective. We can easily track and manage code changes, commit updates, and maintain a complete history of changes for our applications.

I would recommend Azure DevOps to others. Before choosing Azure DevOps, I would advise considering the need for better project management, consolidation of management tools, and streamlining deployment processes.

Overall, I would rate Azure DevOps as an eight out of ten.

We integrate the report pipelines with Azure pipelines, automating the creation of pipelines and initiating deployments automatically. Our process includes continuous integration, deployment, and branching strategies.

The tool's most efficient feature is the integration of its services in one place. It is an easy-to-use product that improves productivity. Microsoft Azure DevOps is also user-friendly. Its documentation is clear and can be found on Google. 

Microsoft Azure DevOps should create some training materials. 

I have been using the product for more than four years. 

Microsoft Azure DevOps is a stable solution. 

The product is scalable. 

I haven't contacted the technical support team yet. 

I rate Microsoft Azure DevOps a nine out of ten. 

My team uses this solution for the CI/CD deployment, and code check-ins.

We are also using Azure Boards for tracking our work, all of the requirements, the backlogs the sprints, and the release planning.

What I like the most is that it is easy to comprehend, and it's easy to use.

The simplicity is very good and the customer experience is also great.

I am not suggesting this solution should be cheaper. I would like to see a bucket of licenses. for example, 10 licenses or 100 licenses that could be monitored to know how many of those licenses have been used. The price would be deducted accordingly.

I should not have to contact Microsoft daily to request a license or two. There should be a mechanism in place where you are able to find out where you are out of 100 licenses, or that you have used 90 licenses in that year.

I should be given a credit line of 10 licenses at the end of the year or at the end of the month.

It should be easier to manage licenses, especially because it's in the cloud. You should know the usage and based on the usage, you should be able to make decisions.

I have been using Microsoft Azure DevOps for one year.

We are using the latest version.

It's a stable product. I have not experienced any issues.

This is an area that has yet to be explored fully. We haven't taken it to this level.

We are a team of 25 to 30 members, which is fine for us. Every time we scale up we need a new license and that takes time, it's not just a click and it's done.

I don't know if it will be scalable for 200 to 300 people.

Previously, I was working with Jira.

I was not involved in the installation. My team completed it.

Price is an area that could be improved. There are products on the market with a fixed price of 50 or 100 people, you are a bucket price. 

With Azure, you have to pay for every user.

It's good to have a bucket such as 50 to 100, or 100 to 200, and flexible pricing.

The issue may be from having more than one license. When you procure one license or two licenses, it becomes difficult.

It should be easier to procure a license, it should not be one by one. We don't know how many members I will have on my team three months from now.

We plan to continue using this solution.

I would recommend this solution, but I would not know their business needs.

Based on the various features, the deployments, licensing, pricing, and the customer experience, I would rate Microsoft Azure DevOps a seven out of ten.