Microsoft Azure DevOps Reviews

We're using Azure DevOps Services for three things: First, for project management, second, for storing the source code, similar to GitHub Repository, and finally, we use it as our CICD build server or build environment, which builds for us and runs tests and so on. In general, these are the three main use cases for this product. We are large customers of Microsoft and we're on a corporate level with them. We pay extra for support. I'm a software engineer manager. 

I like that this solution is all-in-one, a one-stop-shop, it's the killer feature. I haven't seen anything that comes close. I guess GitHub will be close soon, but that's it, there's really nothing right now for that full integration. Other solutions require three tools so this is really a great feature. The solution has a better user interface and better CICD tools compared to what we used previously when we ran TeamCity. I think it scores higher on most things, including better developer ergonomics. Since it's Git-based, there's no training because everyone uses Git. I've found it to also be very customizable so that on all points it's better. This is an important tool for us. 

This solution is not as good as Jira when it comes to project management and I think they know it, but it's good enough. I'm very used to it now, so I can work more quickly, but I've had colleagues who are very Jira-focused and they don't like Azure DevOps at all. When it comes to the handling of tickets or tasks or the product backlog, Jira is much more customizable and more intuitive. It's an area that Microsoft could improve. 

The instructions could be a little better. We are doing some weird stuff where we're building some things, including embedded firmware. It wasn't super intuitive to set that up which was an issue although it's something minor and we managed to solve it. I just expected it to be a little easier, although it's not what the solution is built for. We're going a little out of the normal use case. It is a little clunky compared to Jira and hosting your own builds could be a little easier.

I'm aware that they're putting money into GitHub to add more features around vulnerability scans and statical analysis and so on, basically taking on cloud and what have you, as well as Vericode that we are using. It would be great if it was built into the tool. I get things from other vendors that are provided out of the box, and it would be awesome for me to have that with DevOps. 

I've been using this solution for several years. 

The stability of the solution is good. We've had a couple of dashboards out and they have a nice page share where they show what's out and what's not. A few months back they had some issues with the Active Directory and we were pretty much locked out of some things. We lost Teams for a while and we use that a lot in Azure DevOps. It was quickly fixed. Otherwise, I'm very happy with the stability. 

The scalability of the solution is good and there's no maintenance required. We're a small operation and we could grow by a factor of 10 and it wouldn't be a problem. This is an SaaS and if you need to take care of it, there's something wrong. We use the solution extensively and soon we'll have almost every piece of software, including all our test automation and embedded firmware there so we'll be increasing usage. 

The company previously used TeamCity, and I have used Jenkins in the past, the grandfather of everything. Azure DevOps is nicer. Jenkins is very configurable, but a pain. I like Azure a lot more and I think this or something like it, GitHub Actions, for example, is the future.

The initial setup is very intuitive. What I think they could work on is the whole permissions model where you have projects and other things which require permissions and which is not very intuitive. You can do almost everything but I want a more granular permissions model that's also easy to maintain. I don't quite like the way it's set up so there's some work to be done there. I think I'd rather do it in text because it's hard to see everything clearly otherwise. If you have a complex permissions system, it's complex to set up and it's not super intuitive. Compared to AWS, which is a very different system, that aspect of Azure is not very intuitive.

I work in an engineering department so we didn't feel the need to get any help with deployment. If you read the manual, create the sandbox, and test it out you're able to roll it out. It's not that hard. 

We're not paying a lot for this product. As developers, we have a Visual Studio license which is basically free. That's how their licensing model works. Then we have a number of stakeholders who need to do edits in the system, but not work with code necessarily. I believe they're paying $5 a month per user. We also have users who only need to read things and don't need code so I set that up for everyone who needs it. We're probably paying a few hundred dollars per month altogether. That's a minor cost for us; we're not currently hosting anything on cloud, so it's a small cost compared to hosting a solution. 

We ran into a few things where we had to pay more because of the number of concurrent building agents. We had capped it low and the developer was unhappy so we paid a little more to get what we needed and that's been good. I don't like it when you get a big bill and you don't know about it. 

I'm somewhat critical of the documentation for certain things, but overall, the documentation is really good. In general, Microsoft is really good at documentation. It's worth taking a few hours to read it and then you'll know a little about how Access works. If you set up a sandbox, you're not going to destroy anything and you'll learn by trying things out. I would still read the documentation and go in parallel so you can at least know enough and be aware that it's safe to get in there.

We are very heavy users in creating small projects and then sometimes deleting them because they weren't useful but I like that model. Create a little sandbox and go build. We have done our own workflows and they are always tested in a sandbox before going live. That would be my suggestion. 

I rate the solution eight out of 10.  

We rely on Azure DevOps for our CI/CD workflows. We use it extensively in our daily operations, particularly for deployments and other IT tasks. We use it for project management and collaboration throughout our software development lifecycle. Our task is to determine if the workflow within our networks is integrated with our ITSM or focused management, enabling us to initiate tracking for these tasks.

The reporting and analytics features of Azure DevOps significantly improve our project visibility and decision-making process. This includes a reporting dashboard and integrated monitoring capabilities. We utilize Prometheus and other tools for monitoring, and Azure DevOps seamlessly integrates with various solutions, ensuring flexibility in usage while maintaining consistent concepts.

Azure DevOps has significantly enhanced the productivity and efficiency of our development team, especially considering our high volume of daily deployments. Developers find it invaluable for tracking changes, generating logs, and creating reports effortlessly. Automation of deployments is particularly crucial for us, given our extensive environment with over two thousand fifty-three instances. The most significant benefit is the reduction in time and effort, leading to a decrease in human errors.

Integrating our pipeline with Jenkins is seamless, particularly for code management using Git repositories. Additionally, for cloud-based applications, we already have native network integration with Azure Active Directory.

As we frequently deploy numerous applications, ensuring the protection and fine-tuning of these applications once they are in production is crucial for minimizing downtime and enhancing availability.

The features of Azure Repos that we find most impactful are those related to source control management within our DevOps code management processes.

If the pipeline isn't properly configured, it indicates a potential gap in the team's understanding of DevOps principles, which can lead to deployment issues. Incorporating security tools directly into DevOps is crucial, as many existing DevOps solutions lack robust security features.

I have been working with it for nine years.

We encountered certain downtime.

It doesn't provide the level of scalability as Jenkins provides. We have approximately forty users in our company. I would rate it six out of ten.

The technical support is relatively satisfactory. I would rate it five out of ten.

Neutral

Deploying GitLab or Jenkins is much easier and involves fewer requirements. Integration with various tools is readily available, especially with Jenkins Blue Ocean, which offers extensive enterprise integrations. When it comes to Azure DevOps, integration with non-Microsoft tools may pose challenges.

For any Microsoft product, Active Directory is a prerequisite, and ensuring its availability on the Azure Standard and Database is essential. This configuration is necessary for setting up the application effectively.

Maintenance is essential due to occasional exclusivity with business connectivity, leading to various issues such as data rate problems and database availability issues.

When compared to other vendors, it is cheaper.

I would recommend other tools like GitLab or Jenkins. Overall, I would rate it seven out of ten.

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.

We are using it for feature delivery.

Before we started using Microsoft Azure DevOps, we didn't really have a mechanism for tracking delivery against a feature or feature delivery. It has really helped us in visualizing what we need to deliver and get consensus across cross-functional teams that it is the right thing to deliver.

It allows us to prioritize an organization-wide backlog, which has really reduced our delivery time for complex projects. In fact, we are in the middle of a transformation program. We managed to kick off the program in a month and start the delivery cycle within six weeks of conception. Before adopting this tool, it would have taken us three to six months.

It is a really easy way to define all of the features that you need to deliver. You can link those features to epics and break them down into user stories. You can also assign the user stories into sprints for doing your product improvement planning.

It is a really simple tool for prioritizing a backlog, assigning that backlog into sprints, and then tracking the delivery by using sprint capacity, points of time, the velocity of the sprint, etc. It is really useful for agile delivery.

There are a couple of things. The tool has a logical link between epic feature, user story, and task, but when you try to generate a report to show the delivery progress against a feature, it is not easy. To see the percentage completion for a feature or progress of any delivery, it is not easy to draw a report. 

It doesn't give you a high-level view of your roadmap for planning a roadmap for delivery and identifying how far you are on that delivery path. There should be the ability to create a product roadmap and then based on the delivery of the user stories, link to the features against that product. We should be able to roll up a view to see how have we progressed against our targets.

When you're accessing it via the web, it works nicely, but it doesn't work for a while if you're trying to access the board via a tablet or mobile device. A lot of the time, we just want to quickly update a task or check a delivery against a sprint by using an iPad or phone. It is not really user-friendly on those devices. It works very well on the laptop but not on other devices.

I have been using this solution for 18 months.

We've had very few issues with Azure DevOps.

There were no issues.

We also use Sparx Systems Enterprise Architect. For business process modeling where you are linking different objects in the modeling domains, Sparx is the most appropriate tool. You cannot model business processes in Azure DevOps.

Azure DevOps is more appropriate as a delivery tool for building out the feature roadmap and defining user stories, tasks, features, etc. It is well suited for taking the data and building it into a delivery pipeline. These two tools don't speak well together. A solution was developed to integrate these two, but it doesn't work very well.

It was super simple. We just needed a username and a password. The board was pre-setup by our administrator. In fact, we didn't even have to go through any real training, even though the training was available. It is really intuitive to use.

Its pricing is reasonable for the number of features that you get and the functionality that you can utilize for the agile delivery, which is what we are using it for. I found it extremely cost-effective.

I would rate Microsoft Azure DevOps an eight out of 10. It is the primary tool that we've been using. It works very well.

The first time I used the solution was to create a build for an Oracle application called SOA. We generated all the features in Azure DevOps to create the build and then we created a workflow. We are partners of Microsoft and I'm head of technology.

We have the histories, and are able to estimate the efforts of each story. It means that I can measure it from each developer and I have the match from each developer. We can also check it from the lead time to see whether there are any problems in storage that may not be mature. It gives us control. 

We use Gitch as a version control and the integration is very good. We are also using the features for the product backlog that's released every day so we have the user histories. We can track it from the histories to the code. You can see all the steps in the life cycle we use with our clients. We also like to use the estimate integration feature where you have two or three developers that estimate different efforts for each history. I think Azure is easy to integrate with any other type of solution to improve your delivery.

I think the templates could be improved. It's not easy making the jump from one project to another so we're now integrating using a different partner. I believe the price could be improved when scaling. It's a simple calculation, the number of users times $11, which is approximately the cost. But if you have a large number of users you should be able to reduce the per user cost the more you scale. I think it's something Microsoft could do for us. 

I've been using this solution for five years. 

This is a very mature and stable solution. 

We have about 100 users; developers, engineers and admin. The platform doesn't require any maintenance but we have one DevOps engineer to support the DevOps for the applications that we integrate with the platform. There are two types of scalability, the first is scaling my team, moving from 100 to 200 users, which is easy to do. The second is structure but  I haven't yet tested scalability in terms of increased structure.

Actually, we don't have a lot of experience opening tickets with technical support. All tickets that we did open were dealt with quickly. 

I used IBM where I worked previously but didn't have a lot of experience with it. 

We had some initial difficulties, because the solution is not commonly used here. Jira and Microsoft are the most common solutions but it's not usual to use everything inside the platform. It was a cultural change that we implemented here in our team and to convince them was more difficult than to use the platform itself. We used an integrator for deployment but we don't do that in every case. In some of our deployments, hosting the most popular software development languages, like Java or .NET makes it easy to create the deployment mode. But when you have different platforms on development, it's more difficult to configure. We're on an SaaS platform, so deployment was very easy.

We have 100 users and the cost is $11 per user. There's an additional cost if you want to use the integrated test plan. You have the option to just change your license and you can use the automated test integrator.

We looked at Jira Confluence and it was our second option. On Jira, we have our environment in Azure, and it was easier to adopt Azure DevOps instead of Confluence. Because Confluence is specifically for Azure DevOps, we can integrate it with everything that we are already using.

It's very easy to start using this solution because the first five licenses are free. As a result, it's easy to track and compare with other solutions and it's easy to scale. 

I would rate this solution a nine out of 10. 

We manage the full scope of all our projects on Azure DevOps, including all of our kits, bags, and user storage. DevOps encompasses the CI/CD process of every build as well as the customer requirements, QA, and deployment.

Compared to JIRA, I think Azure DevOps is missing some management elements, like some reporting features. It would be helpful if some things were clearer when we're adding attributes. For instance, sometimes we want to add some categories or attributes, and it's not so easy.

I've been using DevOps for approximately four years.

Azure DevOps is mostly stable.

We've used Microsoft support but for .NET Core or Azure DevOps.

Installing Azure DevOps is pretty straightforward at the installation or admin stage. Deployment time depends on the service on my side, so it's mostly very fast.

It's a great product for the CI/CD process, but DevOps lacks some features for project management, guide, user story, etc., so it's far from perfect. Compared to monday.com, JIRA, or others, they have some work to do.

In the first years, we had the solution, we did not use it for all of its models - not for the full life cycle. Now, within the past year or year and a half, we wanted to make the best out of it. We now use all the models and all the development lifecycle.

The product has integrated all the relevant models of task management requirements, source control, back management, test management, et cetera. You have a full ALM suite.

The connection to Git, which was bought by Microsoft, is also good. We use Git as a version control tool. 

Microsoft has good integration with its other products, such as Office, Teams, et cetera. 

The solution has proven itself to be very mature and robust. It's quite stable.

The scalability potential is very good. 

I'm not sure if "missing" is the right phrase, however, I am interested in, with all of these tools, if the connection to requirements management tools like DCRM, DOORS, et cetera, would be possible. That's a weak spot in most of the vendors.

We would like some bidirectional synchronization. It's the requirement if you want to analyze it to software requirements, et cetera. That's something that most of the tools aren't that good at.

I've been using the solution for around three or four years at this point. It's been a while.

The product is mature and robust and quite stable. I haven't experienced any problems at all with it. It doesn't crash or freeze. It doesn't seem to have bugs or glitches that affect it. We have the support in-house on servers and we haven't had any problems with defining collections for example.

It is my understanding that the solution is very stable. As an example, our organization has many teams and many departments and we use it across them all the time with no problem. We started using it originally when we had several teams, and now we have tens of teams, and it scaled up to meet our needs and we haven't had any issue with doing so.

We also use Jira. I myself do not use Jira, however, it is used by other teams and colleagues within our organization.

I can't speak to the implementation process, as our IT handled it. I was not a part of the initial setup. I can't speak to if it was complex or straightforward, or how long it took to set up.

We are currently evaluating both Jira and DevOps against each other. We use both in several development units. Lately, I've been looking for some comparisons and reviews, and material regarding those platforms and the comparison between them. I'm wondering to myself whether it's good for our company to have both, or to choose one of them to be the standard platform of our company. That's the main subject that I'm interested in.

We are customers and end-users. We don't have a business relationship with Microsoft.

I'm a manager, and therefore I don't personally use it on a daily basis anymore, however, I manage teams that work directly with the product.

I'd rate the solution at an eight out of ten. If I compare it against other products, it holds its own. It's quite a good solution overall and we've been happy with its capabilities.

I would recommend it to other organizations or companies. I'd advise them, however, to use the source control and to wisely choose which kind of collection they want to set up and configure. It's something very important that will set a company up for success. 

I used Azure DevOps for work item management, sprint planning, source code repository, continuous integration, continuous build, and continuous release. I build whole chains.

The most valuable feature is that it's fully integrated, where we have a single place to do everything that we need.

Testing is really good, it has come a long way.

It is the single source of proof or the single system of record that does everything you need, you don't have to put the different pieces together to form the whole chain.

We can do everything in one single platform, which is why it does a good job.

Requirements management is an area that can be improved.

Integration with Microsoft teams would be a good idea.

I have been using Microsoft Azure DevOps for five years.

It's stable. It's been pretty good, especially in the last two years.

There are no issues with scalability. We have approximately 50 people in our organization who are using it.

We have contacted technical support and they are excellent. I would rate them a nine out of ten.

I am using a mismatch of tools from HP and Atlassian, but they did not give us an integrated toolchain. Microsoft Azure does it exceptionally well.

It is reasonably straightforward, but it is only as straightforward as the problems that you are trying to solve.

If you are trying to set up the whole chain, then the problem is complex, and the solution has to be as equally complex.

The price is reasonable, but of course, you can find others that are cheaper such as Atlassian. But, if you look at the more serious products like Polarion, it's very competitive. 

If you have good Microsoft programs, it's nearly free.

I would certainly recommend this product.

There are a lot of parts to the toolchain for DevOps, so take each area at a time. My advice is to take one step at a time, don't overdo it, and over time build out all of the capacity difficulties. Automation is also one of the biggest things.

Overall, it seems like a really good solution.

I would rate it a ten out of ten.