Introduction to Build Automation with Gradle

Kunal Dabir

About me

What do we Build?

  • Libraries

  • Web Apps

  • Micro Services

  • Mobile Apps

  • Native Apps

  • CLI Apps

What do we Build?

Artifacts

What do we have?

  • Source Code

  • Resources / Assets

  • Configuration

What do we have?

Material(s)

What do we depend on?

Other Artifacts, like libraries, which are not built by us

What do we depend on?

Dependencies

Who downloads dependencies for us?

Native Apps: 

brew, apt-get, yum

 

Language Libraries:

 NPM, Bundler/RubyGems, Bower, Cabal, PIP, Maven, Ivy, Gradle

Who downloads dependencies for us?

Package Managers

Where can we get dependencies from?

  • Maven Central

  • Corporate Nexus /Artifactory

  • NPM

  • RubyGems

Where do we get dependencies from?

Repositories

Different Repositories have their own formats like Ivy, Maven, NPM, etc.

Remember Recent NPM fiasco? leftpad?

Repos should be immutable

What do we do with built Artifact?

  • Deploy it (to servers)

  • Publish it (as library)

  • Publish it (to app stores)

Where do we publish?

Repositories

Internal or Public

What does a Build Tool do?

  • Compiles source code

  • Runs automated tests

  • Manages dependencies

  • Runs application locally

What does a Build Tool do?

  • Runs static analysis of code

  • Checks code coverage

  • Produces reports

  • Runs database migrations

  • Web assets optimizations

What does a Build Tool do?

  • Packages distributable binaries

  • Publishes artifacts

  • Generates (API) Documentation

  • Tags releases in VCS

  • Deploys application to servers

What does a Build Tool do?

  • And many more tasks...

Quick Poll

  1. Does your project have a build script?

  2. How do you manage dependencies?

  3. How many steps does it take to publish /deploy artifact after checking out project from VCS

Everyone Reinvented the wheel...

 

 

... in their favorite language

Moar! yeah ...

  • Pants from Twitter,

  • Buck from Facebook,

  • and Bazel from Google

Other Build Tools

Evolution

Bash Scripts

Make

Ant

Maven

Gradle

why not write build scripts in just any scripting language?

because they don't speak the language of the domain (terms used in build) 

 

Why not use IDE as build tool?

  • heard of CI?

  • think of other teammate's preferences?

  • ....

 

why not just a task runner? (ant, grunt, make, rake)

because you have to repeat yourself in every project you build

 

why not maven?

  • Maven did many good things in its time

    • Introduced Dependency Management

    • Brough Conventions

  • But

    • XML is verbose

    • Deviating is cumbersome

  • ...

  • Declarative

  • Repeatable

  • Correct

  • Fast

  • Parallel

  • Polyglot

  • Self-contained 

A Good Build is

A good build automation tool helps us reduce the time and effort it takes to build correct artifacts in a repeatable manner

- Kunal Dabir :)

Gradle

What makes Gradle better

  • Rich DSL

  • Excellent dependency resolution

  • Out of the box plugins (sensible defaults)

  • Fully configurable / extensible

  • Terse and easy Groovy syntax

  • Performant

  • Flexible Multi Project support

What makes Gradle better

  • Vibrant community & ecosystem

  • Open source

  • backed by a company

  • Good adoption

Imperative v/s Declarative

  • Imperative Mixes 'how' with 'what'

  • provide steps for execution and ordering.

  • Looks easy at start, hard to maintain and update

What makes Gradle better

Gradle embraces domain modelling as a core tenet. Focusing on the domain model as opposed to the execution model (like prior generation build tools such as Apache Ant) has many advantages. A strong domain model communicates the intent (i.e. the what) over the mechanics (i.e. the how). This allows humans to understand builds at a level that is meaningful to them.

Who is using Gradle?

Gradle Plugins Portal

Domain Model of a Build

Project

Task

Domain Model of a Build

Project object contains collections of Task Objects and many other methods

Domain Model of a Build

Each Task is an Object on which we can call methods to configure it's behaviour

Learn By Doing (Demo)

Create a task

task hello 

hello.doLast {
    println "I am a task"
}
task hello {
    doLast {
        println "I am a task"
    }
}

Or

Task ordering

task bye << {
    println "I am another task"
}

bye.dependsOn(hello)

Plugins

apply plugin: 'java'
apply plugin: 'war'

Repositories

repositories {
    mavenCentral()
}

Dependencies

dependencies {
    compile 'org.springframework:spring-core:4.0.6.RELEASE'
    testCompile 'junit:junit:4.12'
}

Running

gradle help

Gradle wrapper

gradle wrapper

./gradlew myTask

Start/Stop Daemon

gradle --daemon

gradle --stop

Questions?

Good Reads

Introduction to Build Automation with Gradle

By Kunal Dabir

Introduction to Build Automation with Gradle

We are living in times where continuous delivery is a norm and deployments can not take more than `one click`. To enable this, a good build automation system is the key that ensures correctness of produced artifacts, increases the speed of Continuous-Integration pipelines, and improves the developer productivity. In this talk, we will start with a short introduction to the various terminologies used when we talk about build automation systems. We will also take a brief look at history of build tools and move on to understand what is required for next generation builds and what are our options. We will then see how Gradle fits the bill as a next-gen build system. We will start with learning some Gradle basics first. We need to discern between imperative vs declarative style of writing builds. We will see what properties of Gradle make it absolutely fun to use. We will see some demos using Gradle. We will also bust some build system myths and unveil some gradle build anti-patterns.

  • 805