Build Automation and The Holy Gradle
If you’ve spent any amount of time working with Java, you’ve probably heard about Gradle. You certainly know about it if you’ve worked with Android Studio. It’s not a language; it’s not an IDE; so what is it? Put simply, Gradle is a build automation tool. You might be asking —
What is build automation?
Building a project is the act of processing the source code that’s already been written and creating a live product that users can interact with. This can include things like compilation, version control, creating an executable file, etc. It is a key step in the DevOps workflow, which you can learn more about here.
Rather than re-building the application each time a team (whether development, test, or production) has to work on it, build automation allows for a standardized build process that is repeated each time the codebase is updated. Here, compilation, automated testing, and version control system updates can all be performed with the same, consistent configurations.
There are many benefits gained from incorporating build automation into a product pipeline.
- Increased productivity as developers aren’t bogged down with the sole responsibility for managing builds
- Improved quality of the product as a result of increased productivity and due to faults being discovered and resolved more quickly
- Stored history of operations that can be leveraged to further investigate any issues that arise
Just to name a few. Now to address the elephant in the room…
How do you use Gradle?
Gradle is a utility build automation tool. It builds applications by compiling, linking, and packaging the source code. This is done through automation, using settings and commands that can be adjusted by the user(s) as per their development needs. There are some key concepts that dictate how Gradle operates.
Project. A project represents a high-level thing to be done. For example, this could be a JAR library, a web application, or an executable. Gradle projects consist of a set of tasks that must be executed.
Task. A task represents a (relatively speaking) small piece of work which the build performs. For example, this could be compiling a class, making a Javadoc, or running some tests.
Build Script. A build script is an outline of the steps that need to be taken to build the project. It is often titled build.gradle, located in the project’s root directory. Gradle builds consist of one or more projects.
Putting it all together, let’s look at a simple example of a “Hello World” project. We’re going to look at the Gradle specific aspects, so for now we can assume the project has a file HelloWorld.class that prints out the greeting and does nothing else. For this discussion, the language used is Groovy, a domain-specific language that Gradle supports. The build.gradle file for that project might look something like this:
plugins {
id 'java'
}version '0.1.0'
Currently, there are no explicit tasks in the build script. The Java plugin is invoked as it is a Java project. The plugin adds some language specific tasks and conventions to the project that Gradle uses when it performs a build, things like compilation tasks and the classpath for the Java source file(s). However, we can add tasks of our own.
plugins {
id 'java'
}version '0.1.0'tasks.register('goodbye') {
doLast {
println 'Goodbye.'
}
}
We’ve created a task called goodbye, defined its actions, and added it to the list of available tasks. Its functionality should be clear enough, even if you’re unfamiliar with Groovy. Now we can execute the task. IDEs like IntelliJ, Eclipse, and Visual Studio Code provide shortcuts and UI menus to execute a task, but for now let’s use a command-line example.
$ gradle -q goodbye
Goodbye.Gradle looks for a task defined by goodbye and executes its actions. The action we’ve provided is some simple code to print out a farewell message. The -q flag here means “quiet” and tells Gradle to suppress log messages, as we’re only interested in the output of the tasks.
This example is benign, but it showcases the strength of Gradle’s build automation. The build script is itself code, utilizing the syntax and performance of Groovy. It can be as robust as the codebase itself, leveraging factors such as task dependencies, task manipulation, dynamic task registration, and more. For more examples, you can look at the Gradle docs page for using tasks.
How are other people using Gradle?
PicPay is one of the leading Brazilian mobile payments platforms. With its massive userbase and scale of product, they were in need of rapid turnaround in deployment. However, they found that they were spending too much time waiting on Android builds and test feedback; it was difficult to troubleshoot the root cause of failures; and they didn’t have enough information to properly evaluate build and test performance, failure trends, and bottlenecks in productivity.
To tackle these issues, they looked to Gradle Enterprise. The Build Cache service offered would speed up slow builds and Build Scans would make it easier to troubleshoot both locally and on the Continuous Integration (CI) server. Additionally, Performance and Failure Trends Dashboards for Android would allow them to gain better insight into build and test behavior.
Within 3 months of utilizing Gradle Enterprise, PicPay saw returns on investment from Build Scan and Build Cache. They were able to cut down on their build and test feedback cycle times and could more easily pinpoint the root causes of build, test, and CI failures, and debug them. On top of that, since they began using Gradle Enterprise, PicPay were able to recruit and retain top talent!
All in all, Gradle is a powerful tool for build automation. It is equal parts simple and robust, widely supported, and offers improvements in optimization and performance. You should strongly consider it for your next Java project.
