Microsoft Azure DevOps Reviews

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.

As an architect, I use Azure DevOps for our projects, primarily focusing on setting up CI/CD workflows. We track tasks and maintain timesheets on Azure DevOps. I collaborate with project managers to define deployment pipelines and ensure smooth deployment processes. While Azure DevOps serves as our project management tool, my main role involves architecting deployment strategies and working closely with the project management team to implement them effectively.

Switching to Azure DevOps initially posed challenges, but as our team became familiar with it, we found it greatly improved our daily operations and productivity. Its streamlined processes made our development workflow more efficient.

What I like most about Azure DevOps is how easy it is to manage projects and control deployments. Once configured, team members can manage deployments if they have permissions. Additionally, the reports feature helps generate itemized invoices for the services provided to clients, which is valuable for billing purposes.

One potential enhancement in Azure DevOps could be integrating more customizable reporting features, particularly for Power BI integration, to provide better insights into project data.

I have been working with Azure DevOps for five years.

Azure DevOps is quite stable.

Azure DevOps is scalable and can be used in distributed environments and for different tenants.

Before Azure DevOps, we used various tools like Jira. We decided to switch to Azure DevOps to have all services unified in one place, simplifying management. The main advantage is having everything centralized.

The initial setup process for Azure DevOps was somewhat complex, requiring documentation and technical support. Migration from previous tools and configuring project guidelines were involved. The deployment strategy involved creating directories, and repositories, setting up environments, and assigning access rights, following a predefined plan. Initially, deployment took about three to four hours, but now, for regular deployments, it typically takes 30 minutes to an hour, depending on project stability. 

For the initial deployment of Azure DevOps, gathering information from various resources is essential, but typically, only one person is needed to handle deployment through the web interface. Maintenance involves regular tasks like backups and occasional updates, requiring minimal effort.

The pricing for Azure DevOps may be higher compared to other tools, but overall, I find it reasonable.

In my experience, integrating reporting and analytics into Azure DevOps enhances project visibility and decision-making processes. We can easily generate reports online to track project status and task progress. Additionally, I have integrated Azure DevOps with other tools like SQL Server, enabling us to gather data for generating Power BI reports.

The most beneficial integrations with Azure DevOps are integration with other project management tools for seamless collaboration and APIs for importing data into applications. Additionally, integrating with personal models allows for enhanced analytics and reporting on resource performance and other project metrics.

The source control management features of Azure DevOps, particularly Azure Repos, are highly effective. We can easily track and manage code changes, commit updates, and maintain a complete history of changes for our applications.

I would recommend Azure DevOps to others. Before choosing Azure DevOps, I would advise considering the need for better project management, consolidation of management tools, and streamlining deployment processes.

Overall, I would rate Azure DevOps as an eight 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.

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.