Gradle is an open source build system. Gradle boasts a rich API and mature ecosystem of plugins and integrations to support automation. Users can model, integrate and systematize the delivery of software from end to end.
N/A
TeamCity
Score 7.4 out of 10
N/A
TeamCity is a continuous integration server from Czeck company JetBrains.
Software Engineering Manager - Edge and Cloud Native Productline
Chose Gradle Build Tool (Open Source)
[Gradle is] a more modern version of open source build tools like Ant and Maven.
Whereas the build config was XML files which were tedious and error
prone, the modern DSL usage of Groovy to write these build files is a
Gradle is good and matches well against market leader Maven with its ease of use, ease of migration from Maven to Gradle and also coding like configuration unlike the XML configuration of Maven
Without the use of Gradle, we have done direct integration with the APIs. This has not worked very well in the case of Android as there are a lot of packaging related actions that Gradle directly takes as part of the plugin. This decision to use Gradle was an easy one.
Maven is a much more mature build tool. The community behind maven plugins has continued to grow over time, and there are several mature products that continue to receive support. Gradle can use some of these features, but appears to be losing steam over time. The effort to …
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.
I have participated in a variety of build environments, from basic shell scripts, to ant, and to maven. All of these tools have a place, sometimes perhaps in legacy code. But moving forward, I would never go back to other more primitive tools (never say never...). The more I …
Maven is the most popular alternative to Gradle, in my opinion. I think that both have their advantages and disavantages so I would advise people to scan through the documentation and example applications of both tools and choose according to their needs and limitations.
Jenkins relies on being open source as the primary driver for its success. This low cost is a huge factor for many companies, both small and large. The professional, free tier of TeamCity offers a huge amount of growth before ever needing to pay anything. I personally also find …
Since we were already making use of other JetBrains offerings, TeamCity had a leg up on the competition due to the ease of integration with these tools. With that said, TeamCity's feature set stacks up well with the competition. Jenkins definitely has some nice features, but …
This application is easy to install and deploy at site than most of the similar solutions in market. Easy user interface is one of the reason it can be installed. However each software have its good points and bad points. Study your organizations case and then only choose …
I would also like to compare TeamCity against Snap-Ci as well as Concourse. We chose TeamCity over all of these tools because of its ability to be set up easily against a restricting corporate firewall. We needed to integrate unit tests, integration tests, pushes to production, …
TeamCity competes against the TFS build, Visual Studio Team services and Jenkins the open source workhorse. The reason for selecting TeamCity was because it was found to be a great fit for all the diverse projects on a spectrum of technologies we have which the TFS Build …
Cloud Services Practice Manager and Principal Architect
Chose TeamCity
TeamCity is a great on-premise Continuous Integration tool. Visual Studio Team Services (VSTS) is a hosted SAAS application in Microsoft's Cloud. VSTS is a Source Code Repository, Build and Release System, and Agile Project Management Platform - whereas TeamCity is a Build and …
I like the quality of Jetbrains products. TeamCity is well supported and regularly updated by Jetbrains. They have an active support forum and most questions are answered quickly.
TeamCity is very extendable and has been able to handle everything we've been required to do.
We've only ever really used TeamCity as a CI platform. Running tests on these CI clusters is worlds more efficient and just plain easier than having to run individual tests on your local machine. You just hit one button here, versus either writing some run script or even worse …
TeamCity is the best combination of price and full features. It has a good web UI and doesn't need a lot of manual configuration files, but it still is incredibly extensible and can do just about any build or release task you set it at. If it can't do it, the odds are it has a …
Jenkins and Team Foundation Server (TFS) are both strong products. Compared to Jenkins, TeamCity is much more mature and polished. Though Jenkins is open-source/free, the cost of TeamCity is a drop in the bucket compared to the total cost of even one project we're using it …
Gradle Build Tool is more suitable with the Java projects. It has helped us to automate the build part of the devops cycle. Its configuration and Groovy script is really easy to understand and can be implemented with ease. It can be used both for automation and manual buids of the projects. Gradle Build Tool is easy to use and easy to integrate.
TeamCity is well suited for an organization using continuous integration, meaning you release code to production often, and an agile project management system. There are free versions available for small teams and enterprise versions available for large teams with many different builds. TeamCity is probably overkill for basic e-commerce or blog website builds that do not require much development after the initial launch
Fully customizable build process. Each step of the build process can be parameterized and customized to address specific needs of particular applications. This allowed us to easily convert from a custom VM-based environment to our current Docker-based environment.
Manages large numbers of build agents seamlessly. This allows us to run multiple builds on many different applications in a most efficient manner.
Build steps can be managed in an arbitrary manner, allowing some parts of the process to proceed in parallel while restricting others to depend on completion of all relevant steps.
I'd like to see a way to specify how to run only certain tests in parallel, I tried this feature and for tests that involve interaction with SQL Databases sometimes I can't because of deadlocks.
Not sure if there is something else, gradle has been working really good for us and they are adding improvements all the time which is awesome. I used to think the performance is a deal but the latest versions are addressing this issue very well
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.
TeamCity runs really well, even when sharing a small instance with other applications. The user interface adequately conveys important information without being overly bloated, and it is snappy. There isn't any significant overhead to build agents or unit test runners that we have measured.
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.
[Gradle is] a more modern version of open source build tools like Ant and Maven. Whereas the build config was XML files which were tedious and error prone, the modern DSL usage of Groovy to write these build files is a great advancement. Also these config files can be inherited from top level to each associated project.
Jenkins relies on being open source as the primary driver for its success. This low cost is a huge factor for many companies, both small and large. The professional, free tier of TeamCity offers a huge amount of growth before ever needing to pay anything. I personally also find the user experience of TeamCity to be much better, both from a look and feel, as well as from an out-of-the-box feature set perspective. The big selling feature of ADO is its native integration with Azure. TeamCity integrates very well with out-of-the-box .NET support and greatly simplifies our use of another diverse tooling outside of the Microsoft ecosystem.
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.
TeamCity was a key contributor to our organization's adoption of Agile.
TeamCity made it possible to KILL "It works on my laptop" conversations with Developers. If it does not compile in TeamCity - the project is not deployable. TeamCity's easy to use interface made it possible to quickly adopt a "Deploy Only from TeamCity" policy, further ensuring TeamCity Builds were the gold-standard for well-configured source code.