Why are we using Gradle?

April 4, 2016

You must have heard that Gradle is becoming a multipurpose tool at Intraway. Let me show you why.

A little history

Build-automation tools have been between us for a long time. They were born to automate building and script execution (both locally or distributed), but when continuous delivery and continuous integration became a standard, these tools became more important than the code itself.

Java ecosystem was the pioneer and contributed a lot to get to where we are, first with Apache-Ant and then with Apache-Maven, both parents of Gradle.

Other languages try some standalone solutions of their own, but when they needed to be integrated with a repository manager (Artifactory or Nexus for example) or a continuous-integration tool (Jenkins, Hudson, Bamboo, Travis, Teamcity) they failed badly.

Our problem

I won’t explain to you why we have a lot of programming languages in use, very complex solutions, even more complex configurations and impossible deployments. Explosive growth means chaos: shit happens.

So, we have PHP that does not have a standard building tool. It uses Composer for dependency management (or, at least, tries to), period.

With C++, we use Makefile, no dependency management, manual RPM generation.

Fortunately, in Java we use Gradle, but that represents the 2%-5% of all our code.

And we have several other languages, like Javascript and Python among others.

In addition to the programming language, we are working to achieve continuous delivery, so we need to accomplish the following steps:

Dependency Management
Compiling
Code static metrics
Unit-test execution
Packaging
Publishing (Artifactory)
Integration-test execution
RPM Generation

How do we do it without going crazy?

And the winner is

Hans Docter and Adam Murdoch. In 2009, they tackled the problem and thought incredible. On September 2009, Gradle 0.7 was born!!!

Of course, the first version was oriented to Java, Groovy, and Scala but, from version 2.0 and onwards, Android and C++ were included natively.

Why is Gradle such an awesome tool?

Some people will say that it is Groovy based; others will mention the simplicity, the big community, etc.

For me, it is the plugin-based architecture that Gradle has inherited and improved from Maven.

With a few lines of code, there is nothing you can’t do. And the best thing is that in Github there are thousands of plugin projects that are already done.

Furthermore, Gradle has a native integration with Artifactory and Jenkins, and supports Maven and Ivy standards. And of course, at “https://plugins.gradle.org/” you can find a plugin for anything you need. We are working to upload our own ones.

Check out these charts that show how much Gradle is growing:

Gradle search word in Google

Gradle Contributors

Over one hundred commits per week on Github

Trust me on this: no doubt, this is the future.

Where is it currently being deployed?

After a little tour with a Gradle project, let’s see where we are using it right now and in future roadmap projects.

The first approach was taken by the Java team in the RT-USA project. Now, they are fully productive.

The second step we made was to introduce to C++ world Gradle as a building and dependency management tool. A third of the projects have already been moved to Gradle.

For more info, check http://technology.intraway.com/practices/cpp/guides/gradle-integration.html or contact C++ Practice Leader.

The latest project we launched is related to Automation Testing. Taking advantage of Gradle’s simplicity, we are working on a new automation framework that will support JMeter, SoapUI and Selenium test suites to run our Integration Tests.

Please visit http://gitlab.intraway.com/groups/Testing or http://technology.intraway.com/practices/testing/ for more info.

Final thoughts

Our products have developed rapidly and aggressively over past few years. Traditional build tools haven´t grown enough to meet our product complexities, and our build processes had become outdated and completely irrelevant in every release.

Gradle comes to rescue us when ‘build processes’ involve much more than simply creating a packaged artifact. We have to reach continuous delivery, continuous integration, and continuous testing if we want to outgrow our competitors.