Microsoft Azure DevOps Reviews

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.

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.

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.

With Azure DevOps, I plan and track my project using Azure Boards, manage my code with Azure Repos, and automate build, test, and deployment processes using Azure Pipelines. This streamlines my development workflow and ensures efficient collaboration and project management.

The most valuable feature in automating our build and release processes with Azure DevOps is the scheduling capability. At the end of each sprint, we schedule automatic releases to QA and development environments, ensuring our latest code gets deployed without manual intervention. Additionally, triggering pipelines upon code upload to the main repository adds significant value to our development workflow.

Azure DevOps could be improved with more security plugins, especially for SaaS scanning and vulnerability scans.

I have been working with Azure DevOps for two years.

I would rate the stability of Azure DevOps as a ten out of ten.

I would rate the scalability of Azure DevOps as a ten out of ten. At our company, it is used daily.

Technical support from Microsoft is very helpful, especially when I need assistance with tasks like migrating work items between Azure DevOps and other platforms. I would rate the support as a ten out of ten.

Positive

The initial setup is easy. Deployment typically takes around ten minutes at most. We have set up an automated process that recreates everything, so even if there is damage to the VM or target machine, we can quickly retrieve and redeploy everything ourselves.

We require about two DevOps engineers to maintain Azure DevOps for our company, which has around 400 users in total.

I would rate the costliness of Azure DevOps at a seven out of ten.

We ensure the security of our company's source code uploaded to Azure Repos by using a SonarQube Plugin and then automate its deployment to various environments like development and QA. Once approved by QA, we deploy to the production environment, passing through our firewall for protection. This streamlined process ensures efficient and secure CI/CD pipelines with Azure DevOps.

Azure Boards has significantly improved our project tracking and adjustability. It is a powerful tool where we can easily trace work items and monitor the progress of our projects.

Azure Boards is a powerful tool for tracing work items and project progress. It simplifies uploading and versioning of project assets and tools, enabling easy refreshes or benchmarks.

Overall, I would rate Azure DevOps as a nine out of ten. I would recommend it to others.

The main use of this solution are to combine software development and IT operations. Also, we use it for automation with version control and microservices. Automation is a core principle for achieving DevOps success and CI/CD is a critical component. 

The application of continuous delivery and DevOps to data analytics has been termed DataOps. DevOps focuses on the deployment of developed software, whether it is developed via Agile or other methodologies. ArchOps presents an extension for DevOps practice, starting from artifacts, instead of source code, for operational deployment.

This solution has offered lots of improvements. The most important improvement was to provide continuous delivery with high-quality software. It helps with version control with automation using CI/CD components. It also helps to develop software using the agile methodology. 

The ability of different disciplines (development, operations, and infosec) to achieve outcomes has been great. Increased focus on test automation and continuous integration methods are helpful. It helps release new features continuously into large-scale high-availability systems while maintaining a high-quality end-user experience.

The most valuable feature is automation with version control. 

DevOps initiatives can create cultural changes in companies by transforming the way operations, developers, and testers collaborate during the development and delivery processes. We can release new features continuously into large-scale high-availability systems while maintaining a high-quality end-user experience. 

Adopting DevOps will also help eliminate the old and monotonous way of agile activity among big IT teams like network, Storage Team, Linux/Unix, Windows, etc.

It’s commonly observed that you cannot just change a company’s culture on command. You can influence the culture, shift it, and while it can evolve over time, it’s nearly impossible to just instruct all employees to simply change the way they think and act about specific things. 

The culture of any organization starts at the top of the leadership hierarchy and trickles down throughout, filling every empty space. It is essential that you get buy-in from the top management down to everyone in the pipeline. 

In order to do this, all involved need to understand the advantages the shift is going to have on the organization and on the team members.

I've been using the solution for the last two years.

The scalability is very good.

We didn't use any solution before.

We also looked at AWS.

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

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

The stability has been great.

The solution is scalable. 

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

Our initial setup was quite complex. 

The presence of Microsoft in the country is limited.

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

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

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

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

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

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

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

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

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

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

It is good for monitoring purposes. We are using the build pipelines of Microsoft Azure. They are also valuable. 

We are facing some problems because the capacity can only be measured within a project. It cannot be measured across multiple projects. So, the reporting needs to be enhanced, and there should be more graphs to be able to easily give the upper management insights about all the employees from different departments. It will be helpful for employee management. Currently, the managers over here are using Power BI for insights because the functionality of Azure DevOps Boards is not enough. So, we have to export the data into another visualization tool and get the results.

We would like to have templates for work items. They are available in the Azure DevOps services on the server, but they are not available in the on-prem solution. We are using an on-prem server, and we are using version 2020.1119.

I have been using this solution for almost four to five years.

It works well. There are no issues.

It is easy to scale. In our organization, some teams are using it, and some teams are not using it. We probably have 80 to 100 people.

Their technical support is good. We haven't faced many issues. As far as I remember, we have had only one issue. We raised a ticket for that, and they resolved the issue.

I have also used Jira. We have more control over Jira than Azure DevOps, but we are using Azure DevOps for our technical side because our VMs and build pipelines are on Azure. So, it is better for us to use one solution rather than using multiple solutions.

It is straightforward. It is not that complex.

In terms of maintenance, we only do maintenance when we have new upgrades. Other than that, we don't need to maintain it much. We have optimized the TFS and Azure DevOps database, and we have done indexing and optimized it. It is pretty good.

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

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

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

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

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

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

The optimization feature in Microsoft Azure DevOps needs improvement.

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

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

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

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

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

Microsoft Azure DevOps is a scalable solution.

Setting up Microsoft Azure DevOps was easy.

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

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

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

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

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

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

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

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