Microsoft Azure DevOps Reviews

We use Microsoft Azure DevOps as a code repository, for task and work management, software tests, and documentation.

The most valuable feature of the solution is task management.

The solution could be made faster because it can be a little unnerving to browse through too many pages and press too many buttons.

I have been using Microsoft Azure DevOps for six years.

Microsoft Azure DevOps is a stable solution.

I rate the solution ten out of ten for stability.

Microsoft Azure DevOps is a scalable solution. In my current company, around 30 users are using the solution. In my previous organization, more than 100 users were using Microsoft Azure DevOps.

The solution makes you faster. You can organize your work in an easy and shared way. You can configure different types of access to allow some people just to read and to be able to modify some things. Since the solution gives you all the benefits of Git, you have a commit history.

We have an MPN subscription for Microsoft Azure DevOps, and it's all included.

Microsoft Azure DevOps is deployed on the cloud in our organization. The product supports our agile project management practices very well. We can configure a process, and it would give you some different types of tasks, like the epics feature, user stories, and tasks. We need very little staff for the solution's deployment and maintenance.

For source control, we use Git repositories that are perfectly integrated into our IDE, Visual Studio 2022. Everything is available, and we can create or pull requests from Microsoft Azure DevOps. We can also manage, reject, and accept the requests. I would recommend the solution to other users.

Using Azure Boards for tracking work items and bugs is clear and visually appealing. It's easy to add tasks. In our current configuration, every time I go inside the tasks and go back using the browser, it doesn't redirect me to Azure Boards, even if I am coming from there.

Since the solution is available as Software as a Service (SaaS), you won't need to do any setup, installation management, etc. It's very straightforward, and there is no particular study required. To a certain degree, the solution is configurable and can suit different use cases. It is working very well in terms of Git repositories. Microsoft Azure DevOps is also very accessible.

You can define tasks using Microsoft Azure DevOps and then reference them when you write a commit message or push code. You can open a previous commit in the browser from Visual Studio, and you can use DevOps to compare some files or to check commits done by Visual Studio. So, the solution is perfectly integrated.

Overall, I rate the solution a nine out of ten.

We use the solution mostly for automation, deployment, generating build, and creating virtual machines.

The build and release management features are valuable. The deployment packages are also valuable.

Requirements traceability must be customizable. It is very difficult to integrate the product with third-party tools. It is all proprietary. It's not very customizable. It should be managed better. The product is not sufficient to generate documentation automatically.

I have been using the solution for three to four years.

The tool’s stability is good. I rate the stability a nine out of ten.

We have around 60 users in our organization.

The turnaround time is high.

Positive

My team set up the solution. It took one and a half years to stabilize.

The tool helps us save reasonably.

The solution is expensive.

Overall, I rate the product a seven out of ten.

Building fast and reliable, amplified feedback loops in all stages of our software delivery and operations lifecycle. The business strives for built-in quality to ensure that everyone have correctly done their job. 

I trust my team with peer reviews of our designs, code, test and infrastructure.

I'm familiar with Azure DevOps in the sense that my group directive has based the administration, architecture, and development on Azure. So whichever hat that I need to wear at the time that's the one I can wear.

I would say that Pipelines is Azure's most valuable feature. Also generally, Azure enables us to create a staging environment through to a production environment in an easier way and then get the code and run that. It also has decent pull requests and things like that.

Azure DevOps is a very cross-platform product. One of the issues that I have currently with the company is that they are using two different parts of technology. They were using JIRA for their sprint work and they were also using Confluence, as well as other Enterprise software. I advised them that all their sprint planning, backlog work, and everything else, can be done out of Azure DevOps from one central place. I know the Microsoft team will always look at improvements because I know that they are constantly looking at improvements to products while listening to their customers and looking at a global scale. I'm keeping my ear to the ground, as I always do.

The product keeps evolving and at the moment there are a lot of good parts There are petabytes of data. Anytime somebody does a pull request or anything else, Microsoft is notified about it. So if somebody, somewhere is always looking at that and watching, that can be a revolutionary product. It's a product that can continuously grow and evolve in time. Even if it is not yet what you call a finished article, it's a growing and evolving product.

Everybody has a slightly different take on what solutions or what part of the solution they would like to be improved. You can always improve a platform. Microsoft is always listening to customers and they will bring out a new version. The platform is quite user-friendly at the moment because you can use any program or language with it. You can't say you need another program, because as far as I'm concerned the main ones can be integrated with Azure. The newer ones like Go, as well as older ones like Python, Java, and PSP,  can all be integrated with that platform.

I suppose when we hear about that release, I have no doubt that because Microsoft captures a lot of metrics and information that they monitor, like capturing data about what or how people use their product, they can see where the usage is and where they might want to remove a feature. That analysis and also comes from Microsoft's monitoring capabilities.

I thought it was very stable. They didn't have any shaky moments. Predominantly with Azure DevOps you need one thing only: a solid internet connection. If you've got a solid Internet connection, you just push everything up to the platform or run an integral request. I haven't had any issues with that. Some people might have, but it all comes down to their internet connection.

This solution is extremely scalable.

It helps a lot in Microservices or service technologies. Using the infrastructures of code enables a productivity increase of a thousand percent. I was speaking with a company that was pulling 12 requests at one time but using competitive technology like DevOps they were able to pull over 2000 requests at the same time. It's extremely scalable and you can use it to scale down when it needs it. It's a completely autonomous product, that allows you to scale whatever you need.

I have five or six back end developers that use it every day. They learn every day, so whatever code or scripts they write are in Azure DevOps. They're not using any another tool to do it, they are pulling it with the platform because you can't tell other people about a platform if you aren't using it yourself. The first thing they do is log on to DevOps.

There will be an increase in our usage of the product. We are looking to expand at some point. The more people that come on board, the more use there is for the product.

We haven't had a requirement to contact their technical support. I have contacted their technical support before under some other projects and got a really good response from the person on the other end of the phone. They are always looking to help you solve more solutions as quickly as they possibly can.

I don't think I have had a bad experience; I've always had continuity. They were able to get me the problem resolved, whether it was a P1 or P4 issue. I've never had a problem with the technical support.

I have experience with Amazon Web Services. As the Azure product has matured a lot in the last two to three years, it deserves its market share at the moment. We were using other products, like Visual Studio, a web service which is an old name for Visual DevOps. We were also using things like Team Foundation Server (TFS). We were just using some of the older tech.

The initial setup was straightforward.

We did the implementation ourselves.

I'm working on the high-level design and the low-level design so I know where we're going to start, and whether we've got a blank slate. I've worked with many firms in the past and companies have their own design in place. Usually, some of these companies material is outdated and Microsoft will probably move the bar several times. We are Microsoft accredited so we stay in touch with the technology more recently than most. We've constantly been informed of the latest technology and the latest products that are evolving on the platform. That includes those that are in preview, which I hope will become available, as well as those that are going to be deprecated. We're basically in full harmony with Microsoft and their products.

We most definitely achieved an ROI.

Check out the pricing information from Azure Cost and analysis information.

No Visual Studio Team Services and Visual code were the preferred options.

The first thing that I would suggest is to read the documentation for the platform. The online documentation changes pretty much every other week; there is always something new coming out. Practice, practice, and practice. Test, practice, and repeat. You need to know your way around the platform and the only way to do that is by hands-on practice. You can't break the environment, but you can speed things up on the thirteenth hour. It depends on how you configure things since every configuration is different. It's an excellent product that is taking into account current technology, yet also flexible enough to use with future technology.

At the moment I would rate Azure DevOps as a nine out of ten. The reason I wouldn't give anything a ten is because it's constantly evolving. There is room for improvement, as this is not the finished article at all. The reason I would give it a nine is the information to get the best usage out of the product is readily available. I've been using Microsoft tech for over 25 years now and back in the day it was difficult to get information out of Microsoft even when you were an MCPN. You would have a special link to go through a Microsoft back door to gain information. That's completely different to the advice that you would get related to Microsoft.com. Now Microsoft is completely different with everything readily available. You can download it in pdot format and the document could be 2000-3000 pages. They leave no stone unturned.

The only problem I would say at the moment is a friend of mine said that the Microsoft test book is taking a long time to come out because he wants to take the exam. Some people need to read the information and retain the information that way. Sometimes you go on these courses that are not run by Microsoft directly. They can be very flaky and don't have all the information or experience of using the product in normal working life.

If there is anything I would ask for, it's to get the documentation out on hardback so that we can add it to our libraries. That would be very good.

We use Microsoft Azure DevOps for CICD, and to organize it in order to visualize the ongoing work.

It allows you to save time while also providing a governance visualization of ongoing activities and transparency.

The most valuable feature of this solution is that it saves time.

The price could be reduced. It is expensive, especially when it comes to infrastructure.

The integration could be better. Being more technology-agnostic through ease of integration would be beneficial. Once you start working for Microsoft, you are frequently tied to Microsoft.

I have been using Microsoft Azure DevOps for the last ten years.

Microsoft Azure DevOps is a stable solution.

Microsoft Azure DevOps is scalable.

I would say the technical support is fine, but I have not had any trouble with the solution.

I have some experience using Jira.

It is very expensive in comparison to others.

As the cost structure is per user, I would recommend paying the cost structure based on the amount of data you use rather than the number of users.

I have recently researched Jira, Microsoft DevOps, TFS, and Micro Focus.

Mostly, because of the pricing, I would rate Microsoft Azure DevOps a seven out of ten.

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

We integrate the report pipelines with Azure pipelines, automating the creation of pipelines and initiating deployments automatically. Our process includes continuous integration, deployment, and branching strategies.

The tool's most efficient feature is the integration of its services in one place. It is an easy-to-use product that improves productivity. Microsoft Azure DevOps is also user-friendly. Its documentation is clear and can be found on Google. 

Microsoft Azure DevOps should create some training materials. 

I have been using the product for more than four years. 

Microsoft Azure DevOps is a stable solution. 

The product is scalable. 

I haven't contacted the technical support team yet. 

I rate Microsoft Azure DevOps a nine out of ten. 

We use it for automating our code builds, significantly enhancing collaboration, and accelerating our release cycles. By reducing release times, we're able to ship our product faster, thereby increasing productivity and efficiency.

We use continuous integration and continuous deployment through Azure DevOps. With CI, we gain the advantage of fully approved code merges, as demonstrated in your demo. This ensures clarity on which releases are destined for production. With continuous delivery, we seamlessly deploy to both our test and production servers.

Azure DevOps supports our agile project management and sprint planning processes. This enables us to release sets of features more efficiently and quickly within the Agile framework. Additionally, DevOps facilitates the approval of features, further streamlining our release process.

When using the Agile template, we have visibility into what tasks are available, in progress, upcoming, and completed. This comprehensive view allows higher management to easily track the current status of tasks, including which ones are being worked on and which are finished.

It significantly enhances the testing phase of our software development lifecycle. Previously, after development, we deployed our software to a common QA environment for testing. However, now with Azure Test Plans, we can create isolated environments for each solution using virtual machines. This isolation helps us identify and address issues specific to our product, without being hindered by environment-related issues. With continuous integration through CI/CD pipelines, once our build is completed and approved, it automatically deploys without manual intervention, streamlining the process further.

Since adopting Azure Pipelines, we have observed significant improvements in our release management process. Previously, the process involved various stages and multiple approval steps, leading to fragmentation. However, with Azure DevOps, the entire process is streamlined, allowing for seamless transitions from board check-in to release approval within the same solution.

Before using Azure DevOps, we couldn't release as swiftly as we can now. With Azure DevOps, our ability to release has significantly improved. This increased efficiency means we can release more versions of our product, leading to higher productivity and the shipment of more artifacts than before.

The features that have a significant impact on us include CI/CD, where we have full integration with the source code repository and Azure Pipelines. This enables us to efficiently review and approve source code for deployment and testing. Utilizing Azure Test Plans, we can deploy to virtual machines, facilitating streamlined processes in a dedicated environment.

At times, our development work encounters issues, particularly when executing numerous CI/CD processes. Occasionally, these processes may experience delays or errors, often stemming from unavailable features or functionality in the cloud environment. Improvement in this area is necessary for smoother and more reliable operations.

We have been using it for two years.

This solution is stable. However, as mentioned earlier, configuring multiple CI/CD pipelines, with numerous processes running concurrently, can occasionally lead to issues.

Being cloud-based, this product is highly scalable, offering the flexibility to scale horizontally or vertically as needed. With a relatively small team of ten to twenty users, the scalability of the product aligns well with our requirements. It is widely utilized by both developers and the QA team.

The initial setup varies depending on the complexity of the workload. Some cases are intricate and require significant time to develop the end product or work item. Conversely, there are simpler, smaller cases that can be completed quickly.

For deployment, assistance from Microsoft or a system integrator is essential. Customizing templates and processes requires their full support to tailor them to our specific requirements. Since it's a cloud-based solution, the need for managers is minimized as management becomes simpler. A team of two to three individuals is sufficient for configuring it effortlessly.

The licensing for this product is on a monthly basis. It is relatively inexpensive compared to other solutions that necessitate servers and physical hardware.

 Overall It offers a comprehensive array of features with accessibility and support for customizations and performance enhancements. Its extensive feature set covers various aspects, making it highly versatile. I strongly recommend Azure's demo for exploring CI/CD pipelines, boards, and customization options. It will undoubtedly streamline development activities, reducing effort and boosting productivity significantly. Overall, I would rate it eight out of ten.