Microsoft Azure DevOps Reviews

All the artifacts are tightly integrated into the repository where you have changed tracking, and you can enforce policies. You can improve the quality of your deliverables. You can actually see the progress you're making towards your goal, and you can even forecast how soon a feature can be completed in the future. So, it's that tight integration of bringing all the parties together right from the project managers to the developers, to the system admin who does the deployment that helps achieve the goal of DevOps. That is, the ease of realization of this DevOps ideal is possible.

Most developers and project managers choose the Microsoft tools to begin with because of familiarity, and these new tools are almost an extension of the tools you're already familiar with. There's a lot of knowledge transfer, which helps, rather than bringing in a new product line.

Also, with Azure DevOps there is tight integration to Excel and Office tools so that you can actually even use Excel to do Azure DevOps type tasks. Excel will automatically update the Azure board, your tasks, your company boards, etc. So, there is that condition and familiarity for users.

What I like about it mostly is the tools. You don't need a degree to use them. Also, there's not too heavy a reliance on the CLI.

Right now, they tend to have a limit of 1,000 tasks per sprint, and some of their web-based boards, such as the Kanban boards, no longer display tasks. Once you hit over a certain number of task limits, you need to increase those limits. Depending on how big the sprints you're running are, once you hit that 1,000 limit, you now have to start grouping tasks together. It doesn't allow you to track granularly. When you go to the boards and you are rendering the task board, it gets slower to go over that 1,000 limit. If they could improve that to, maybe, 10,000 and still have good performance, that'd be great.

I've been using it for eight years.

The version we use right now is the 2020 version, but usually, we try and keep within the last two versions.

Depending on the organization, it can be deployed on-premises or as a cloud solution, usually with Microsoft Azure as the cloud provider.

It's very, very stable.

I've used it in organizations with multiple departments using the same installation, and it's scalable. We have about 20 users in multiple departments.

Microsoft support is excellent. Even when you don't have support for some lines, you can call them, and a lot of times, they'll give you what's called a grace case. This means that although you don't have a support contract on a product, they'll help you for free.

Normally, when you call and don't have a support agreement, Microsoft will still charge you an hourly rate to give you an engineer to work with you.

Microsoft Azure DevOps just provides better integration than Jenkins does. I've been in this industry for 27 years. The whole ecosystem and the fact that most of the developers are already using Visual Studio make Microsoft Azure DevOps a good option, along with the entire integration from the project management side, to the development side, to the repository side, and to the deployment side.

Installing Microsoft Azure DevOps is straightforward. You can have everything set up in three or four hours. It's pretty simple.

I've used Jenkins in the past and a group of source repository. I've also used SourceSafe and GitLab.

To run it, to use the tool the way it's designed, you need someone who understands Scrum or Agile project management.

I have used GitLab and other pipeline tools like Jenkins. Azure DevOps combines all of them together, and it beats all of them at everything they do.

On a scale from one to ten, I would rate this solution at nine and advise others to go for it.

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.

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.

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.

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.

There are many valuable features including dashboards, sprints, queries, pipelines, artifacts, and the cover repository.

I would like to see improvement in the metrics and the dependencies. I would also like to see the option to define the dependencies within all teams in the same project. We have a team level, a program level, and a portfolio level. For the metrics portion, I would like to see some drag-and-drop features for the dashboards that would make it possible to aggregate data from the different teams.

The plugin for the iteration walls can also use improvement as it does not work well.

I have been using the solution for three years.

It is stable. Whenever there has been an issue the solution slowed down but there was never any data loss.

The solution appears to be scalable.

I am not familiar with the initial setup.

The implementation was done in-house.

The cost is reasonable. For the basic license, it is around five euros per month. 

I rate the solution nine out of ten.

If someone is considering developing and deploying the infrastructure in this solution, then using this tool is perfect because it's fully integrated with the pipelines and with a server core repository. When you are building infrastructure, then you are able to use the same tool to deploy the server, deploy infrastructure, and all within a few minutes. This gives you access to the same tool, task management, dashboards, pipelines, and the server core repository. So everything you need to develop a server is integrated into the same tool.

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.