Microsoft Azure DevOps Reviews

I work for a telecommunication company that offered television via IPTV. 

IPTV is an internet protocol television, such as AT&T U-verse or Fios from Verizon.

All of the IPTV systems are proprietary, meaning that's not open to the customer, only to the infrastructure. Before Microsoft Azure DevOps, customers only use what are called set-top boxes. When you are deploying Microsoft Azure DevOps, you don't need the set-top box anymore. You only need a client that can go in, but you have to deploy it. You have to understand what the customer has and what they needed to have in place for on-premise, hybrid, or in production.

Microsoft Azure DevOps does not use the set-top boxes. You have something else that is called OTT or over the top. What that means is the deployment that you're going to do depends on the client the customer is going to use. The deployment has to be tested, and that's why we have the different deployments available, on-premise, cloud, and hybrid.

The most valuable features of Microsoft Azure DevOps are high-level protection. The protection is very important to the customers to prevent eavesdropping. eavesdropping is when a hacker tries to get into the solution. With this solution is it difficult for them to do it.

In the hybrid deployment, you can test everything. The customer was perfectly happy that developed the code, and when they put it in the hybrid Microsoft Azure DevOps and tested it as if it were in real production. That's the part that I've really enjoyed the most, is seeing how a product that was developed by the customer was tested perfectly. If something is wrong, we come back to Microsoft Azure DevOps for whatever they need to do. If they need to go deeper, they can use TFS which is part of DevOps and show it to the program manager or developer.

Microsoft Azure DevOps needs to be updated in my time. In the application that I was managing myself in the deployment and support, it was updated every six weeks. The customer had new features or new batches. Batching is an update of the software. Unfortunately, some of the DevOps or some of the people that were working on that part, do not have the final experience from what customers have. This is something that I did with several teams in Microsoft. We told the product unit manager if you want to understand what is happening from a customer standpoint you need to start from the beginning. Having customers find a problem can not be the only way to find issues to resolve them. 

Testing is very important. Microsoft Azure DevOps tests very well. However,  DevOps teams need to be aware of what they are impacting when someone updates anything on the system.

I have been using Microsoft Azure DevOps for approximately 

It's important to know what kind of DevOps you are going to have. If they're going to work with Microsoft Azure DevOps, they need to understand the solution very well. They cannot just start doing things because they wanted to try and do them.

Microsoft Azure DevOps is scalable if you have everything in place, such as the service map and processes. Before you do anything, you have to understand what the impact will be on the customer.

We had over 10 million people using this solution worldwide. I have worked in many countries, such as the Americas, Canada, and Chile. Many of our product groups were in China, India, France, and Israel.

I have used Amazon AWS previously.

When I compare when Microsoft Azure with Amazon AWS. The two of them offer the same features. You have the storage, performance, connectivity, et cetera. However, on the hybrid, Microsoft Azure DevOps is a lot better than Amazon AWS because you can emulate it perfectly. The hop counts matter, which is how many times one communication connects on its travels from one device to another.

There are three ways to deploy Microsoft Azure DevOps. To set up all three deployments is very similar but different. The on-premise deployment is where the customer owns the code. What Microsoft Azure DevOps does lets you develop your code, and when you have finished your code, you have to put it in the cloud for the hybrid. Then you can test it in an environment that is similar to production. I was in charge of making sure that everything was set up correctly.

I was involved from the beginning of the implementation. I'm a project manager myself too. I don't have certification, but I've been doing project management all my life. One important element when doing the implementation is the voice of the customer. No matter what you're configuring or setting up, if the voice of the customer is not there, but the voice of the business and the employees is, that is only two-thirds of what you have to do.

For example, I want my customers to run this application even if they are in the jungle. If they have access to WiFi, cellular signal, or hotspots, they can have access to anything that Microsoft Azure DevOps can give to them. Except they need a client, and that's the other part. You need to understand what clients the customers are going to need. The clients depend on three things. You need to know the infrastructure of the customers, their immediate needs, and the needs of their customers. We're developing something for the customer who has customers. Unfortunately is not only DevOps, it's everything. DevOps is only one part.

DevOps has one issue. There are components that are produced and supported by other teams somewhere else. Service maps are very important to develop with DevOps teams. When we develop the service map, they know what to do. However, some DevOps do not like to have service maps, because they say that they know what to do. That's what the problem is, they need to understand that they're not alone.

I have worked with integrators, vendors, resellers, consultants, and in-house teams.  

You have to be a very good project, delivery, and program manager, in order to understand how to work with vendors.

For example, you need to know how to work with people who, are going to cable a house, building, or something similar. You need to understand specifically what are the requirements that they have as a company. Additionally, you need to understand the company to know the requirements of the customers. If you are not familiar with any one of those, the deployment is going to be a total fiasco. You have to know what is going on. 

You have to know the vendor. The vendor can tell you a lot. For example, when the materials are available, if there is a problem with the supply chain, what do in this circumstance. The vendor knows about the RMS or the return of the devices. You have to know everything from the deployment, such as RMS to return back, refunds, purchase orders, and goods received.

The return on investment from Microsoft Azure DevOps depends on how many customers you have and how fast are you going to be able to have something ready for your customers.

I have a customer who wanted to start quickly on the cloud. They have about three million customers working in one area, and only when 100,000 started did they receive a return on investment. It was not immediate but in approximately a year or a year and a half, they had a return on investment with every single customer.

The reason that customers are going to the cloud is that it provides the ability to reduce the license cost. For example, when purchasing Office 365 it is bundled with Word, Excel, PowerPoint, Access, and many other applications. In the past, purchasing a license was approximately $600. Today it's only $35 or $45 per customer, per client, or per user, plus the storage. It's less expensive for companies today, to use something, such as Microsoft Azure DevOps, and provide the software to all the employees needing a license. It's better to go with the cloud than just to buy the licenses by themselves.

There are some additional costs. You pay for how much space you are using. If you don't use too much space, then the price will be very little. If you use a lot of space, you have to pay for it. Additionally, they offer readiness training. It is not included directly in what is called a statement of work when you are doing business with customers. This is when things can be a little more difficult because it can be expensive for customers if they want to change deployments from on-premises to cloud or hybrid.

The voice of the customer is very important. Develop the software based on the voice of the customer.

I rate Microsoft Azure DevOps a seven out of ten.

As a software development team, we use Microsoft Azure DevOps extensively across various functions. We rely on its capabilities for source control, enabling us to efficiently manage our codebase and facilitate collaboration. Additionally, we leverage Azure DevOps for test management, including the creation and execution of test cases and test plans. Furthermore, we utilize its features for project planning, tracking work items, and generating weekly documents to ensure smooth progress tracking.

Azure DevOps has been instrumental in facilitating agile project management and collaboration within our team. We extensively utilize all the features offered by Azure DevOps, enabling us to seamlessly handle tasks such as test management, project management, software defect resolution, and source code management throughout the software development cycle.

We are leveraging the capabilities of Azure Repos for our source code management needs, finding them highly advantageous for our workflow.

Azure Pipelines have significantly improved our deployment process by enhancing automation. We utilize Azure Pipelines to standardize our build process, ensuring consistency in our artifacts and maintaining high-quality outputs. Additionally, it has enabled us to enhance our testing procedures, leading to more efficient issue detection and resolution.

Azure Test Plans have significantly influenced the quality of our releases. Acting as our test engine, they have played a crucial role in ensuring the quality of our software. Post-release, all identified defects are thoroughly addressed, and developers are requested to provide corresponding test cases to prevent recurrence of issues.

Azure Port is considered the most valuable feature.

When comparing with Jira, I find that the task management capabilities in Azure DevOps are not yet fully comprehensive and should be enhanced.

We have been using it for three years.

It provides good stability. I would rate it eight out of ten.

I would rate its scalability capabilities seven out of ten. Currently, approximately ten individuals utilize the platform. However, we plan to expand its usage in the future.

The initial setup was fairly complex and time-consuming. I would rate it four out of ten. During the initial setup, we encountered the most difficulty with Microsoft's documentation. It proved to be quite lengthy and lacked clear guidance, which made the setup process challenging. Consequently, we had to explore various additional resources to ensure a smoother setup of Azure DevOps.

For our initial deployment, we allocated one DevOps engineer who dedicated approximately one and a half months to complete the setup.

The cost is quite affordable.

The initialization process may pose some challenges, but I find that the investigation aspect is handled quite effectively. Overall, I believe it's well-suited for both general and specialized DevOps use cases. I would rate it seven out of ten.

I work in a consulting firm responsible for adding, managing, and deploying government projects. We are using Microsoft Azure DevOps in one of the projects for backlog management, test planning, test execution, sprint planning, bug fixes, and enhancement requests. We use the solution for anything related to development testing.

The solution's most valuable features are backlog management, build release pipeline, and testing. They're easy, intuitive, and increase productivity. Usually, if you don't use such a solution, you end up using Excel. Then, you won't have shared documents, and there'll be no single source of growth. Everybody will keep a different document somewhere, and you will spend a lot of effort reconciling the latest status.

Using Microsoft Azure DevOps makes it really easy for us. Anytime you can see how many bugs are open, you can directly get it out of the tool. The solution's reporting is really easy. You can create ad hoc reports based on management requirements. If you are sitting in a meeting and somebody asks you the number of chain requests, bugs, or enhancements, you can create quick queries and show them the status. I think this directly affects productivity.

Microsoft Azure DevOps doesn't have an ITSM tool compared to its competitors. We also use Jira for another project, and Jira supports ITSM or ticketing. Since Microsoft Azure DevOps doesn't have this feature, we have to depend on another solution for service request management for support tickets.

The solution should include ITSM tools and security. DevSecOps are third-party security plug-ins that you can integrate with DevOps. Azure DevOps itself doesn't have anything out of the box. Enabling security so that the solution automatically starts checking things would be a really handy feature.

I have been using Microsoft Azure DevOps for three years.

We haven’t faced any issues with the solution’s stability.

I rate the solution a nine or ten out of ten for stability.

Since it's a SaaS solution, we haven't faced any scalability or performance issues, and we haven't struggled when we had a lot of users. We have gone through a curve. We started with around ten users. At the peak of the project, we had almost 50 users. Since we are in maintenance, we have come down to 10 to 15 users.

We use 100% of Microsoft Azure DevOps for our project. Everything is within Azure DevOps. If anybody says that we need to work on a feature, the first thing we do is create a DevOps item. So, we don't do anything outside DevOps.

The tool provides the features, but we haven't been able to onboard end users. We are a consultancy firm that works with system integrators and also engages with the end client. We have been able to onboard the system integrators, and we are also using it.

However, the end users still prefer sending emails and documents. If you send them a link to run a test script, they won't do it. So, the end users still prefer the old ways, such as emails and documents.

I rate the solution's scalability a nine or ten out of ten.

So far, we haven't faced any issues in terms of technical support. There is good documentation available if you are looking for support for configuration. So, you usually end up resolving your issues yourself. Since this tool is widely used, you can find help online. People are writing content about this solution, and Microsoft itself has good documentation.

On a scale from one to ten, where one is difficult and ten is easy, I rate the solution's initial setup a nine out of ten. The solution's initial setup is pretty easy, and the rollout is pretty quick. You can enable it and then keep on modifying and updating it.

It took us less than a week to deploy Azure DevOps. Since we were using a cloud environment, there was no infrastructure requirement. We went on Azure DevOps, created an organization, and then created a project. Inside the project, we selected the type of project.

There are different templates that you can follow, including the CMM-level approach or the basic approach. We selected one of the templates and copied the template. We made some modifications to the template for the project because that template is used for governing steps.

Then, we created depositories, which is pretty quick. In a week's time, we were up and running with backlog management. It took a couple of weeks to complete the automated build and deployment pipelines.

We needed one person to set up the project and one knowledgeable about the build and deployment pipelines. If you have a person who knows how to do the pipelines, you can also configure the project. So, one person is good enough to set up the entire project.

We have seen a return on investment with Microsoft Azure DevOps in terms of productivity because it really helps with the amount of time you need to consolidate reporting and planning. The status is always up to date, and the deployment is very streamlined. You can do the entire thing in Excel, but the overhead would be too much, and you would lose out on things. So, team synchronization and productivity are the return on investment with the solution.

I rate the solution’s return on investment a nine out of ten.

The solution's pricing is pretty cheap. The best part of the Azure DevOps and SaaS model is that there's no upfront cost. The tool has a per-user license. It's free for five users, and there is a price above five users. The solution's deployment and licensing costs are very cheap compared to those of its competitors.

The solution's pricing is not fixed. The solution's testing license is $50 per user. It's $15 for normal users who use backlog management. We have two people from the test team and seven from the other team. This is in maintenance.

Since we had a big testing team, we had 15 people in testing and 30 people in backlog management during peak time. You can say it has a 70:30 ratio. Most of the cost is in testing, and the backlog management is really cheap.

On a scale from one to ten, where one is cheap and ten is expensive, I rate the solution's pricing a three out of ten.

Before choosing Microsoft Azure DevOps, we evaluated other options like Jira and HP ALM. Jira is good at ITSM and backlog management, but it is dependent on third-party tools for pipeline deployment.

It's too complex to do product management with HP ALM. It's a good ITSM tool, but the process it follows for product management is very stringent, which is not very flexible for sprint planning. There is too much overhead in HP ALM to do quick sprints.

We are working with the SaaS (Software as a Service) version of the solution, which is on the cloud. Since Microsoft provides the latest upgrades and patches, it should be the latest version.

We start by creating backlog items. Whenever we get a requirement, we log it into Azure DevOps and plan the backlog. The backlog includes what features we need to develop and what tasks we need to assign to each developer. Each developer is part of the DevOps. Once you have created that backlog, we assign it to different developers based on a sprint.

Suppose we are going to run a four-week development cycle. So, we plan the development cycle, pick a few items from the backlog, assign them to that sprint, assign them to the developer, and then manage the execution of that development cycle. Once that's completed, we will transfer it to the test team so they can test it in Azure DevOps.

They have test scripts that are documented in Azure DevOps. They run tests, record videos, and capture screenshots in Azure DevOps. After the test verification, we deploy the solution. In addition to backlog management and product management, we use Azure DevOps for build and release deployment. We don't manually go and build the software.

Our code repository is also part of DevOps. As soon as we check in the new code, Azure DevOps automatically builds the solution and then deploys it in the development environment. Once it's confirmed, the same is deployed to quality and production. We use the solution to do everything end to end, other than ITSM.

Specifically, Azure DevOps is integrated with deployment for us. When we manually deploy a solution, it's prone to errors. We use Azure for website deployment and Azure DevOps for Apple app or Google app deployment.

As soon as the approval is done in Azure DevOps, apps are automatically published. It will publish an app on the Google Play Store, Apple Play Store, and Azure, which we use for web hosting. So, it is integrated with web hosting, Apple Store, and Google Play Store.

The solution does not really need any maintenance. Once you enable the testing solution, you can start creating your test plans and test scripts directly. Every time you do a deployment, you just need to run those test scripts, which is pretty easy. It's more about creating your test script than configuring the tool. Even if I do it in Excel, I need to spend time on that.

The solution's analytics and reporting are pretty easy. We use them very often on an ad hoc basis whenever we discuss and plan what to deploy and what the next steps are. It's pretty easy, and we haven't faced an issue where we weren't able to take out any reports just by doing it on an ad hoc basis. It's pretty easy, and you don't need to write code or anything.

The tool is pretty flexible and easy to use. I suggest starting with the cloud version because you can create your project easily. Since it's free for five users, organizations with budget constraints can start playing with limited users. I would say start with the cloud-based version and start playing with it. Once you get comfortable with it, you can expand it for other projects. The tool serves a wide variety of use cases.

The biggest key trend these days is fast deployments or quick releases. Given how competitive the market has become, you need to keep on adding features to your product. Azure DevOps supports the sprint methodology, which supports fast deployment.

On top of that, it supports automated build release deployment. That was a headache when I started working. Sometimes, you forget a file when deploying in production, and your system will go down. The solution's features support the latest fast or quick deployment trend.

Overall, I rate the solution 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. 

Azure DevOps is primarily used as a DevOps tool rather than an AI tool. It is used for source code management, setting up repositories and pipelines, and it can handle a range of workflows from the DevOps stack.

The tool helps by being an all-in-one solution where I can store secrets, code, and pipelines. This comprehensive nature has made it valuable and helpful by improving customer productivity and allowing me to perform multiple tasks without needing additional solutions.

Azure DevOps is highly valued for being an all-in-one solution. It offers capabilities like source code management, secret storage, pipeline management, and more, making it comparable to a multitool that does not require integration with other solutions. I appreciate it for its scalability and ability to handle different workflows effectively.

A notable improvement would be adding more notifications. It would benefit from more seminars or events where Microsoft encourages other users to transition to Azure DevOps.

I have been working with Microsoft Azure DevOps for around two years.

The stability of Azure DevOps is rated as stable and simple, with no complexity involved. I have not experienced any outages or downtimes in Azure DevOps.

Azure DevOps is highly scalable and receives a rating of ten out of ten. It can handle various volumes of workflows, which makes it effective for different use cases.

I have not communicated with technical support for Azure DevOps.

Neutral

Azure DevOps does not have a complex setup process. It requires Microsoft Azure for the services used, and the product itself is simple to set up.

The pricing of Azure DevOps is rated at five out of ten. It is mid-range pricing. It is considered to offer good value for money even if setting up an agent separately is required.

Our discussion mentioned Jenkins as a popular CI/CD product.

Azure DevOps is a very powerful tool with almost every feature necessary for DevOps, so it is recommended to other users.

I'd rate the solution eight out of ten.

We are mostly using Microsoft Azure DevOps for the development dashboard and for CI/CD pipelines. We also use it mainly for Git repository management.

We are primarily using Microsoft Azure DevOps for its Git repository management and CI/CD pipelines.

Service monitoring should be improved. This feature is available for Azure DevOps in the cloud but not on-premise. It can be enhanced to be used with on-premise solutions.

I have almost three years of experience working with Microsoft Azure DevOps.

This solution is stable. Its stability rating is eight out of ten.

I have not contacted Microsoft technical support; I rely on the documentation.

Positive

I did not use a different solution before using Microsoft Azure DevOps.

For me, the initial setup experience would be rated a seven out of ten.

The deployment takes only a few minutes. That said, it depends on the size of the artifact. If the artifact size is large, it will take a bit more time. We did not use any third-party services; we handled it in-house.

I have no idea about the pricing of Microsoft Azure DevOps.

I did not evaluate other options. We had to listen, as we were already using the solution.

I recommend Microsoft Azure DevOps. It is user-friendly.

I'd rate the solution eight out of ten.

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.