Microsoft Azure DevOps Reviews

We use it for requirements, development work, and testing. 

We're doing an implementation at the moment with the client. So, it is the latest version that would've been uploaded.

It is a cloud-based system. So, it is stable and scalable.

Azure DevOps is set up more for development and less for testing. If it is set up correctly, everyone can use it better, but it was set up from a development point of view, which means it is lacking in what I need from a testing perspective. Just like any other tool, it depends on how it is configured. I am not happy with the way it is set up. It is configured more from a development side, and it doesn't necessarily cater to all the other areas that probably need to use it, such as testing data, etc.

I have been using this solution for about 15 months.

Its stability and performance are okay. It is on the cloud. As long as you have got access to it, it is stable.

It is a cloud-based system. So, you can add more bandwidth. It is scalable on the cloud.

We have about a hundred users who are using this solution. It is used on a daily basis.

A third party deals with the technical support of it at the moment.

I wasn't around when they initially set it up, but the way it is set up, it is too complex. It is probably good for developers, but it is not good for the testing side. 

It is a third party that sets it up. I don't know about its maintenance because I'm not that close to it.

I would advise organizing and doing the right assessment for all teams that are going to use it. When it is being set up, more people within the program need to be involved in the setup, not just the developers. You need to know about the requirements for design, development, testing, integrations, and architecture. You need to solicit requirements on what each one of these teams needs from the tool before the tool is configured. When you set something up only from the development perspective, you forget that there would be a need to extract information for data testing and training. So, you need to assess who all are going to use the tool so that you set it up for maximum usage.

At this time, I'd rather not recommend it because it wasn't set up correctly. It wasn't set up with other teams involved. In a year's time, if I'm working on it again, I may have a different opinion.

I would rate it a five out of 10.

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.

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

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.

We are using Azure DevOps for continuous integration and continuous deployment.

Microsoft Azure DevOps has helped the developers a lot and we are deploying process changes very frequently and simultaneously. A lot of my team members that are developers are updating the code in parallel using Git. Additionally, Microsoft Azure DevOps is providing a very good approval mechanism. Overall it is benefiting by creating efficiency in production deployment and applications, our new releases are running well. The security of secured is good.

We are facing a lot of issues in the development of containerized solutions. We are facing a lot of challenges in this area. They could make the process simpler.

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

The technical support from Microsoft Azure DevOps is good. Whenever we have raised a ticket with priority, we had a very good response from the technical team. My experience with Microsoft support is very good.

The integrations of Microsoft Azure DevOps are good and the implementation is not difficult. The testing of the solution went well.

I have seen a return on investment from using Microsoft Azure DevOps.

We have spread the knowledge about Microsoft Azure DevOps to a lot of our customers. We have organized a lot of training sessions because we are Microsoft's gold partner. That is why we promote all the tools and technologies which are part of Microsoft and we're also using them.

I rate Microsoft Azure DevOps a nine out of ten.