Azure DevOps Services vs. Gradle Build Tool (Open Source)

Before using Azure DevOps, the department was calculating metrics by hand. It was a very tedious process that, at times required duplicate effort. Once we added the online boards, we were able to let the cards automatically calculate dates and provide us with team metrics instantly. It is also great for being able to easily move features from one team to another. Before we added all teams in the same project, it would require us to re-enter the features. We move features around a lot so that has been a big help. I also like the board customization, not all of our teams follow the exact same Agile flow, so allowing each board to have its own columns, states, and notifications give flexibility to each team.

Gradle is an ideal tool to build an application that is complex and/or distributed. It is well suited for builds that use a CI engine such as Jenkins or Bamboo, and a repository such as Artifactory.

• Flexible Requirements Hierarchy Management: AZDO makes it easy to track items such as features or epics as a flat list, or as a hierarchy in which you can track the parent-child relationship.
• Fast Data Entry: AZDO was designed to facilitate quick data entry to capture work items quickly, while still enabling detailed capture of acceptance criteria and item properties.
• Excel Integration: AZDO stands out for its integration with MS Excel, which enables quick updates for bulk items.

• Build Cache - Enables quick build on dev machines
• Supports multi project builds - enabling modular architecture
• Customizable build tasks
• Support for multiple JVM languages

• Need to make the changes so that it doesn't occupy most of the CPU utilization and memory
• Execution of Bulky SQl Queries leads to either the SQl being out of exception or the VS being unresponsive
• Integration with Microsoft products is easy, but with non-Microsoft products it is more difficult, and you have to make a lot of configuration changes to integrate
• With every upgrade of the Visual Studio, like from VS 2010 to VS 2013 , we need to upgrade our hardware/machine, as the VS hardware requirement also increases
• If code is getting compiled in one visual studio, like in VS 2010, that the same code could possibly give an error when compiled in VS 2013, due to certain changes in keyword, data format, etc., with the VS upgrade

• Still under development, not as mature as Maven
• Build files aren't as easy to follow because they are so loose
• The community isn't as large as Maven

I don't think our organization will stray from using VSTS/TFS as we are now looking to upgrade to the 2012 version. Since our business is software development and we want to meet the requirements of CMMI to deliver consistent and high quality software, this SDLC management tool is here to stay. In addition, our company uses a lot of Microsoft products, such as Office 365, Asp.net, etc, and since VSTS/TFS has proved itself invaluable to our own processes and is within the Microsoft family of products, we will continue to use VSTS/TFS for a long, long time.

Azure DevOps is a powerful, complex cloud application. As such there are a number of things it does great and something where there is room for improvement. One of those areas would be in usability. In my opinion it relies too much on search. There is no easy way to view all projects or to group them in a logical way. You need to search for everything.

Gradle's language construct is good

I have tried to use Gradle for projects several times in the past, but there is just so much work in maintaining the build file that it quickly becomes untenable. I have been using Maven for many years, and even though the build file can be complex, it works without maintenance between releases.

When we've had issues, both Microsoft support and the user community have been very responsive. DevOps has an active developer community and frankly, you can find most of your questions already asked and answered there. Microsoft also does a better job than most software vendors I've worked with creating detailed and frequently updated documentation.

Gradle has been an excellent tool for Android development. It has helped us create multiple versions of the app for different environments. It also takes care of all the packaging needs in the background without having to write all the code related to that. It is a no brainer to use Gradle with Android applications.

Was not part of the process.

VSTS is great if you final source system is Microsoft based. Everything work well together and once you learned how use VSTS it isn't difficult to build more build systems. If your staff are used to the methods Microsoft uses, their time learning VSTS won't be as difficult as staff that do not know the Microsoft way of doing things. If, however, you are going to build non-Microsoft bases applications, such as Java, Ruby or even Python, Jenkins is probably a better choice.

SBT works fine for Scala but when I tried to use it with Java it was hard to configure and I gave up. Maven is awesome but the pom.xml file tends to be really big which makes it hard to read. Grunt is suitable only for js projects.

• Via acquisition, we had some Atlassian tools including Jira, bitbucket, and confluence licenses. Total cost for 25 users was close to $5000. Migrating the team to VSTS would net savings of close to $2500.
• If you're running TFS, you can save costs on: server licenses (you'll have at least 2 - one TFS, one build server). Save time on maintenance and upgrades of TFS.

• In a distributed development environment, once we established a strong CI/CD model, Gradle proved to be a great choice to automate the various processes. Gradle also provides much flexibility, which is essential in today's development environment. The important benefit is that the CI/CD engineers can support development's needs quickly and reliably. This in turn supports faster testing and deployment, which generates higher ROI.