Microsoft Azure DevOps Reviews

We use it to manage the project. We create the product backlog, and we put our tasks into the DevOps schedule.

Azure DevOps allow you to create a bridge for maintenance and support, directly to the client. We can forecast tasks and the number of hours a task will take and can compare it with how long a task actually takes. The Timetracker function allows us to put all this together. Before Azure DevOps, we had difficulty predicting how long tasks would take, considering all the parts that must work together.

We have a component server, which is basically a tracker. This is very useful for us to itemise the start and end of tasks to evaluate the resources required, based on price. So it's very valuable. It is important to be able to inspect the items required in a project.

The communication could work better, especially for the development team. The important thing is that the tracker tools provide adequate communication, as do other tools. It seems to be lacking in DevOps and is an area which could be improved. We also need to improve publishing in production. In the future, we would like Azure DevOps to work with automated tasks regarding publishing. Better integration with existing source code is another area, which would benefit from improvement. The search repository could be more comprehensive, and visualisations could be optimised, further.

We have been using Azure DevOps for around two years. We are a Microsoft partner, so we use Azure DevOps as part of that partnership.

Stability is excellent. Initially, we had some problems with performance, but nowadays it's okay. Maybe they improved the server.

It's good scalability, but we need to improve the process by understanding it a lot more.

We never actually contacted support. The best plan is to read through all the documentation, but getting the right documentation for your specific project is not always easy to find, as there is so much to go through.

It's average, because we need to research what we are trying to achieve, and the platform has rich functionality. This is a good thing, but it can also mean setup is very complicated. However, we usually find that after testing more, we find our way around what we are trying to achieve.

Our deployment took about three months, as we tracked it. Following that period, we needed another month to integrate a new component into the setup. We implemented it ourselves, with one of our team. We have about 10 users using Azure DevOps, but we have 2 people to provide the deployment out of those. These are developers. We have a small team for DevOps, including the manager. We need our staff to be flexible and agile in our team to take on various DevOps tasks.

As a Microsoft Partner, you get a discount on the pricing. Licensing costs are around $80 a month for DevOps, but for Azure, it is about $200 a month.

We tried other tools, but Azure DevOps has a richer toolset, and it fits in better with our process. To some extent, as we are a Microsoft partner, we didn't seriously consider other options. However, we did look at Jira and Gitlab as potential alternatives.

I would rate Azure DevOps as an 8 out of 10. I would ensure that DevOps' use is planned, in detail, including the implementation before using the software. I would also ensure you have a thorough knowledge of the main components of the system. This will ultimately save hours of work.

My team uses this solution for the CI/CD deployment, and code check-ins.

We are also using Azure Boards for tracking our work, all of the requirements, the backlogs the sprints, and the release planning.

What I like the most is that it is easy to comprehend, and it's easy to use.

The simplicity is very good and the customer experience is also great.

I am not suggesting this solution should be cheaper. I would like to see a bucket of licenses. for example, 10 licenses or 100 licenses that could be monitored to know how many of those licenses have been used. The price would be deducted accordingly.

I should not have to contact Microsoft daily to request a license or two. There should be a mechanism in place where you are able to find out where you are out of 100 licenses, or that you have used 90 licenses in that year.

I should be given a credit line of 10 licenses at the end of the year or at the end of the month.

It should be easier to manage licenses, especially because it's in the cloud. You should know the usage and based on the usage, you should be able to make decisions.

I have been using Microsoft Azure DevOps for one year.

We are using the latest version.

It's a stable product. I have not experienced any issues.

This is an area that has yet to be explored fully. We haven't taken it to this level.

We are a team of 25 to 30 members, which is fine for us. Every time we scale up we need a new license and that takes time, it's not just a click and it's done.

I don't know if it will be scalable for 200 to 300 people.

Previously, I was working with Jira.

I was not involved in the installation. My team completed it.

Price is an area that could be improved. There are products on the market with a fixed price of 50 or 100 people, you are a bucket price. 

With Azure, you have to pay for every user.

It's good to have a bucket such as 50 to 100, or 100 to 200, and flexible pricing.

The issue may be from having more than one license. When you procure one license or two licenses, it becomes difficult.

It should be easier to procure a license, it should not be one by one. We don't know how many members I will have on my team three months from now.

We plan to continue using this solution.

I would recommend this solution, but I would not know their business needs.

Based on the various features, the deployments, licensing, pricing, and the customer experience, I would rate Microsoft Azure DevOps a seven out of ten.

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 are using this solution for CI/CD projects, for Scrum, Agile planning, testing, and business management system solutions. 

We are also using it for continuous integration, and continuous delivery of DevOps.

I am also using the Git Repositories, which is the main source control for me in the organization. We were using it on-premises and now planning to move it to the Cloud.

They are calling it repository and they are supporting an old protocol, which is a popular protocol called Git repository.

The most valuable features of this solution are the CI/CD pipeline, and the testing automation.

It's good that they are bringing more options to this environment, and to deploy to virtual machines.

The testing agents needs to be improved, they need to work on it.

They can enhance the areas related to continuous integration and build automation. They can add more technologies for the build.

The integration with the Azure infrastructure as a code and include more templates for infrastructure as a code in the continuous integration phase and the build phase.

They can add more flexibility to the continuous deployment.

Artifact management is also an area that needs some enhancements.

I think automation and integration with the CI/CD lifecycle it's good but it's using agents.

I am using a different tool for testing automation because I have not found any use cases on it. This feature is not covered. I'm using only testing and business management. I'm not using the testing automation feature that is provided by Azure DevOps.

I would like to see more integration with other platforms and more flexibility.

They have to add more features such as schedules and more flexibility in the platform. This will allow me to build my space and time based on the schedule and based on a calendar.

I would also like to see a release calendar so that I can plan my releases based on my sprints. 

This is required and it would give this solution more maturity. Between Scrum, Agile Planning, or Project planning with the build and deploy prophecies.

I have been using Microsoft Azure DevOps for three years.

We are using the latest version of this solution.

It's a stable solution. We have not experienced any issues.

It's a scalable product. We have more than 50 users in our organization using this solution.

I plan to continue using it in the future.

Previously, I used TeamCity, Jenkins, I used Chef, and many other technologies.

The initial setup is straightforward, it's a cloud service, so it's plug and play.

I would recommend Microsoft Azure DevOps for other users who are interested in using it.

I would rate this solution an eight out of ten.

We primarily use the solution for our Agile teams, however, we started off using it with our executive suite. Our executive team now meets in sprints every day. Sometimes it's a short 15 minutes, other times it can be up to an hour. We have two-week sprints and daily scrums associated with it. We've also rolled that down from the executive. We've got seven formal Agile teams running throughout the organization across our businesses. We probably have at least 40% of our staff now trained in Agile and using DevOps to execute the projects.

As an Agile team, we're now able to move much faster than we could, even pre-COVID.

Typically the sprints themselves and managing the tasks have essentially eliminated our need for reporting. That in itself has had a huge effort on the number of meetings. In the past, you would almost wait a month before you could get all the executive teams together. Now, we've got meetings daily. Due to the regular meetings, we're utilizing daily scrums and two-week sprints, and we've been able to move a lot faster than we've ever had before as far as initiatives. 

Frankly, throughout this whole COVID situation, being able to respond the way we have to some of the changes that were going on has been amazing. I don't think that would have happened if we weren't an Agile team.

There are a lot of features that we could probably work with a bit differently as we learn more about the tool. Right now, we're just really using it from a task management perspective. We've only been using it a year. There may still be more to learn and unpack.

Some of the queries, the way they're built, need to be looked at. We need better query tools.

Being able to report back to boards, to regulators, and the activities and stuff would be helpful. The queries do require somebody else to actually write them. There should, however, be a way to make things a little simpler in that space. Right now it's on us to figure out how to get better at making queries effectively and in such a way we're just not reporting on tasks complete.  

We track the associated feature story. In many ways you can actually go back and see the story, and see the progress you've made on initiatives due to the fact that you can see all the decisions that have been made along the way. If there's a way that person could dig into that and pull more information or insights, that would be very helpful as it would assist us in improving future projects or even help us forecast on an existing project. 

I use the solution daily. We launched it in the company in January. We've been using it across all our Agile teams here for 12 months here.

The stability of the solution is very good. I haven't had issues with bugs or glitches. It doesn't crash or freeze. It's a reliable solution.

The solution's level of scalability is good. We're a smaller organization. We've only got 300 people in total, and out of those, probably 40% of our entire staff use the product. About 120 people probably are in there on a daily basis. That's everyone from executives down to programmers. It's extremely cross-functional across our organization.

I haven't had to reach out to DevOps themselves personally, so I wouldn't have experience there. However, if we ran into any issues, my technology teams would contact them.

We didn't previously use a different solution. That's why we looked for an automation tool. We switched to DevOps mostly due to the fact that our development team was utilizing DevOps as part of their own Agile operations. A number of teams were also already sort of experienced. There are a number of individuals in the company who were experienced that way, and we had homegrown support in some ways when we launched it. It just made sense to go with DevOps as opposed to bringing in something new.

The initial setup wasn't complex. It was pretty straightforward. We didn't run into any issues that complicated the process of implementation.

We did look at Jira briefly, however, it didn't look that different from DevOps and we knew many of our team members were already comfortable with this solution so we didn't pursue it.

We're just Microsoft customers. We don't have any business relationship with the company.

I'm not sure which version of the solution we're using.

I'd strongly recommend the solution to other organizations. I can't see us ever reversing back now after being on this for a year.

Overall, I would rate the solution at an eight out of ten. It's relatively easy to use and it does what we need it to do.

We use Azure DevOps to place our corporate servers into the cloud. We perform evaluations in the cloud for clients. Occasionally, we provide a hybrid solution in a specific cloud. For corporate work, we usually use a different cloud. With Microsoft Azure DevOps, as with any DevOps, it is not always possible to identify specific use cases. How do you identify a specific feature from a hundred requirements into a specific use case? It is very easy to lose detail. Traditional teams and ways of working methodically for safety-critical systems are not always prepared to handle that. It is important to be able to handle hundreds of detail-oriented requirements.

Azure DevOps is now used for safety-critical systems, whereas in the past the traditional approaches were used in requirements management. This is more like the traditional waterfall model. Improvement is always unique to productivity. That's why we switched to Microsoft Azure DevOps. The software teams prefer it to IBM.

We can eliminate some of the middleman processes. In the process, we are merging DevOps with development and operations. So developers act like our operation team as well. That concept is a great exchange. It brings a high level of visibility. It helps the team and department cohesion, which helps to improve productivity. 

It also includes a high level of traceability and elimination of some of the unwanted silos in productivity. Testing and transparency need to be defined within the boundaries. If a backlog occurs, you should be able to group them as a whole. This means there is a backlogging to the team, as opposed to individual areas. Each area needs to be visible to other areas, at all times.

Microsoft needs to consider ruggedization and addressing specific disciplines. Fundamentally what I mean by that is you cannot merge everything. It should be able to handle the different types. There is ecosystems engineering, and there is software applications engineering. There is a need to bring these teams together, but the disciplines don't integrate very well, and so it won't work. For example, there is expertise in an area, and they tend to view the project from their own perspective. 

For example, the software UI/ UX team needs to view it from the UX perspective. Application engineers need to view it from the application viewpoint and the engineering perspective is different again. Although we need to be cohesive in our approach, we need to keep some boundaries as well. The idea of containers arises, such as those provided by the open source software product Kubernetes. We need to containerize different disciplines and then merge them. As a manager, I should be able to ask the formative team to focus on their creative section, and that their task is completed. In the Application layer, you also focus on their requirements and you establish traceability. Other teams may also be involved in linking to the overall requirements.

I have been using Azure DevOps for one year. It has been used in the company for about two years. It is used in the cloud and on-premises, as a hybrid cloud solution.

We implemented on-premise as a hybrid solution, and on the cloud.

I would give Microsoft Azure DevOps a six out of 10. Microsoft Azure DevOps is not perfected yet, as it needs to be more user friendly. If it can achieve that it will eventually reach a 10.

What I like the most is the DevOps Boards. It's easy to create a hierarchical project structure, assign tasks to people, and then track their tasks.

I also like the scheduling functionality.

I would like to automate notifications on sprint planning. When we are getting to the end of sprint planning, we would be automatically notified. 

Also, it would be nice to have a percentage complete. For example, if a task is in progress, how much of it is complete, how much is left outstanding. I'd like that to be something that the assignee fills in and that automatically reports back to me.

I have been using Microsoft Azure DevOps for six months.

It's a stable solution.

Microsoft Azure DevOps is scalable.

I have not contacted technical support.

Previously, I used Microsoft Project. We chose to use Microsoft Azure DevOps because I needed something that my stakeholders could access.

The initial setup was very straightforward.

The time it takes to deploy is dependent on the type of deployment. Deployment of software, or deployment of the project into the software? 

It took me a week to deploy the project into the software. It's approximately 800 PBIs.

Before implementing Microsoft Azure DevOps, I would suggest doing your research on how to configure it. It is a product that I recommend

I would rate this solution an eight out of ten.

We normally use DevOps. On the application, everything has gone DevOps, however, we don't use the functions. All applications developed there have gone under Azure or AWS. We normally develop them to be able to not be dependent on anything, so if we want to deploy them in another environment, we can deploy them easily. If we want to use it in Azure, we use it in Azure. If we want AWS, we use it in AWS.

I like the CD pipeline. It's the most valuable feature for us. It's so easy to integrate into the CD/CI environment. I mostly love that one.

The initial setup is quick and easy.

The functions have too much dependency right now, so it makes it really, really hard to upgrade and make a change in the code. 

If you want to use the DPR it's a bit harder due to the fact that it's only 30 days.

We've been using the solution for a year and a half at this point.

The stability of the product has been good so far. I can't say that I've witnessed glitches. There aren't bugs. It doesn't crash or freeze. It's reliable, as far as I can tell.

We don't have any issues with the scalability of the solution. If we need to, we're able to scale.

We've never contacted Microsoft for technical assistance. 

We are Microsoft partners. We have several Azure experts on our development team, and we have a tech that came from the US and did the training for us. We have a very strong understanding of the product and therefore we don't need help with troubleshooting or anything of that nature.

We also currently use AWS, however, I prefer Microsoft's solution as it's a bit easier to use overall.

We did not find the initial setup to be complex. The implementation is straight forward. 

Deployment is quick and typically only takes a few days or so.

We have ten people that handle maintenance. They are in different parts of the world. We have two in Australia, for example, and two in the USA.

The cost can get pretty high if you aren't paying attention to what you are doing.

We're partners with Microsoft.

I'd highly recommend Microsoft, and I recommend it more than any other solution. Everything is very simple and straightforward. The only worry for some organizations may be the cost. You need to be really, really careful.

I'd rate the solution overall nine out of ten. I think it's really, really great. If the functions were a bit better, I'd give it a full ten out of ten.