Microsoft Azure DevOps Reviews

My clients use Azure DevOps primarily for managing code deployment pipelines. We follow a structured process of pushing code from the development environment to testing and then to production, and Azure DevOps is crucial in this workflow. We leverage its version control capabilities to maintain and track our codebase efficiently. Additionally, we make use of its dashboard service to monitor and manage employee hours, helping us keep a close eye on project timelines and resource allocation.

The most valuable aspect of Azure DevOps for me is its robust version control functionality, which is critical for our workflow. I find it particularly useful how easy it is to automate pipelines. When we push code changes, the system automatically runs the entire pipeline, and the clear visualization of logs is a great benefit. This feature allows us to quickly pinpoint issues and understand what went wrong with our processes or tools, making troubleshooting much more efficient.

While there is always room for improvement, I don't have any urgent issues or specific feature requests right now. I'm content with Azure DevOps as it is. Its functions are standard and easy to use for those familiar with such tools. However, the only thing that could be improved is the stability of the solution.

I have been using Microsoft Azure DevOps for two months.

The solution is generally stable but not entirely issue-free. While problems do occur occasionally, they have become less frequent, occurring around six times less often than before. For example, a recent issue occurred when a dependency was updated, causing the pipeline to crash. However, with the help of logs and troubleshooting, we were able to identify and resolve the problem by making adjustments to the Docker file. I would rate the stability as an eight out of ten. There is room for improvement in terms of stability, as there are occasional issues that require manual intervention to address. While progress has been made, there is a desire to achieve a level of stability where network removal is not necessary in the first place.

Azure DevOps is highly scalable and works effectively even for large-scale projects. It can handle the demands of extensive engineering work and is generally robust in terms of scalability.

The technical support is good and quite responsive.

I have experience with using GitLab. Comparing GitLab and Azure DevOps, GitLab excels in functionality and offers excellent integration capabilities with Azure DevOps. However, Azure DevOps has a more user-friendly UI. The choice between the two depends on specific project needs and preferences.

The installation of Azure DevOps is straightforward because it is a web-based platform. You don't need to create solutions or go through complex setup procedures, making it a user-friendly option. Maintenance for Azure DevOps is minimal, especially if you have automated processes in place. If your solution uses Docker and you have set up automated updates on Docker Hub, the environment can essentially upgrade itself without much proactive maintenance. However, if issues arise, you can make adjustments to the configurations as needed, allowing for a more reactive approach to maintenance.

My advice to those looking to use Azure DevOps would be to make good use of the documentation available on their website. It is a valuable resource that can help answer questions and provide clarity on various aspects of the platform. Overall, I would rate Microsoft Azure DevOps as an eight out of ten.

We have separate DevOps processes for different teams. We're implementing agile processes, so we have cells for each product, and each cell has its own DevOps process. This means we have a DevOps process in GitHub, GitLab, and another tool. We have lots of costs and can't share experience between teams.

The idea was to unify everything in one product to ensure that we standardize DevOps practices on the same tool to have better knowledge and expertise and focus on a specific tool.

We had a lack of governance over DevOps processes, so we had some quality issues in the end when we released the software products. DevOps has helped to resolve those issues.

Azure DevOps' collaborative features are good, and it integrates well with other tools in the software development process, like quality testing, documentation, and agile development. 

I think Azure DevOps could improve the traceability or business intelligence about the execution of DevOps processes. 

I've been using DevOps for three years.

Azure DevOps is scalable. 

We have good people with a lot of experience in DevOps, so it's not complex for us. The most significant difficulty in adopting the tool was changing our past processes to move to the standardization model we defined with Microsoft DevOps.

We have a yearly agreement with Microsoft to cover the different companies.

I rate Azure DevOps nine out of 10. I would give it a perfect 10 if Microsoft offered personalized support. Sometimes we call Microsoft with requests, and it would be nice to have personalized processes with our specialized services.

We have two different approaches for products. One is to support products that we provide our customers. The other is creating a digital transformation strategy for new products. We are using DevOps in the latest products, and in the future, we are going to grow with support for products we have produced in the digital transformation. This is part of our roadmap to implement DevOps in all the processes in every technological area of our companies.

The purpose is for development and testing from the vendor side. Our company works as a vendor, client, and implementation partner. The vendor provides the product, and we make sure that it's implemented correctly for the client. The vendor uses it for the development and tracking of the requirement and the test cases, executions, and building storage.

My access to these tools is very limited because the DevOps pipeline and DevOps is mainly used by the engineering team of development, but the QA is also part of it. Once those people are established, then we are the extended hands or extended part of that for usage. Once they have the stories and features, they start the test cases and link on it. From that point, we just take it forward and once they have a code pull, then we would pull it and build it and deploy it into some QA enrollment.

There are around 20 people using DevOps in my company.

The best tool would be Azure DevOps. There are other tools with AWS and Google, but since Microsoft has solutions for everything, it's easier because it's all their tools. We may be using different tools in order to achieve all those things because they may not have an operating system or a pipeline, so maybe we are using some of the bill tools. In order to achieve DevOps, you may be using a set of different tools and connecting it. In Microsoft Azure DevOps, you have a one shop to get everything.

There isn't a requirement traceability matrix format. In ALM, we have a centralized repository of all the requirements in one place. But in DevOps, it works like a product requirement. In ALM we have the centralized repository of requirements where you can go and see the requirement coverage and discovery and so forth. But in DevOps, it has stories and test cases. Once that project is over, nobody is going back into that requirement. It's a good tool for development activity, tracking and getting all those metrics. If they can build up a requirement traceability matrix, then it would be great.

I haven't seen any issues with stability.

The scalability of DevOps is good.

We haven't had any issues with technical support. Whatever issues we've had, they were solved.

I didn't see any complexity in the setup because everything is from Microsoft. The development tools and operation tools are coming from one shop, Microsoft, so it's easy to connect, plug in, and establish all those things. For Google Cloud or AWS, it's different because they use different tools in order to achieve what Microsoft is trying to achieve. For example, the CI/CD Pipeline.

Even in ALM or in the DevOps tool, it's initially a one-time setup.

I don't know the pricing of DevOps. It would be much cheaper than ALM because ALM came out as a software product initially. Now they are moving into a cloud and subscription model. In that case, Microsoft is coming from Azure and the cloud and DevOps and software as a service, so it would be much cheaper, but the catch would be that they are trying to get money on all sides, like an operating system, Microsoft Office, or Microsoft Azure DevOps. 

The good part is that it's a complete package, but at the same time, once you've gone with them, you don't have much leverage to split out into some other activities because everything is interconnected and entwined by that time, and it would be like a monopoly. It won't be good if you try to split out at a later point in time because everything is connected—all our Microsoft products like operating systems, OfficeSuite, MS Teams, Azure DevOps, etc.

I would rate this solution 9 out of 10.

I primarily use the solution on projects often. We use it for our Git repository and the CI/CD.

I love how easy the solution is to use. It’s intuitive. I don’t need to reference a manual. Everything is just very naturally laid out.

You can link your tasks and assign people. To me, it just makes sense. The user experience is excellent.

I like the Kanban tasks and their various features. It’s all very straightforward.

The one thing that really stands out to me is how you can filter and how you can do your reporting and filter the tasks and everything by user. Every time I try to do that in Jira, for example, it's a pain.

The stability of the product is quite good.

I’m not sure what needs improvement. I don't even think I'm using everything. There are still a lot of things on the testing side that I'm not using. That said, there's, there's a lot that it can do. I wouldn't even know where to get started on discussing what it needs or lacks.

We did have some brief performance issues, however, that was due to putting everything on one epic instead of breaking a project up.

I’ve been using the solution for about four years now. It’s been a while.

For the most part, the stability is very good. There was one time there was a bit of a performance issue, however, it was just due to the fact that the project manager was overwhelmed. It slowed down and got laggy. We put everything on one story, one epic, and we realized we needed to split it up.

The product can scale. With the projects that I work on I just pick up Azure DevOps. It just makes sense. Everything from the beginning, for example, how the story starts right up to how it gets deployed and everything, is well laid out and you can adjust as needed.

On the project that I'm doing right now, maybe have a team of ten. On other projects, for example, at my previous company, we had a hundred devs or so using it.

Technical support has been very good. We used to call Microsoft and they would help us. They gave great support. We’re quite happy with their responsiveness and level of knowledge.

I also use Jira alongside Azure DevOps. I use both of them.

I find DevOps easier to use and better laid out. I find Jira difficult and confusing.

The initial setup is pretty straightforward.

I can’t speak to the exact pricing. It’s not an aspect of the product I deal with.

We’re a customer and an end-user.

I’m a big fan of DevOps. It’s a good project and I haven’t seen anything else like it.

As we’re on the cloud deployment of the solution, we’re always on the latest version.

I’d advise new users, if they are a Microsoft shop, to choose DevOps over Jira. It just makes more sense.

I’d rate the solution at a ten out of ten.

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.