Gradlebuilding great tool

me

szczepan faber

lives in krakow/poland

lead at Mockito

core dev at Gradle

soccer junkie (idzie, idzie, idzie, …)

gradlewhat do you know about Gradle?

build tool

decent feature set and very active development

always open source and free

sustains its own conference

world domination in progress

gradleware

looks after Gradle

offers consulting

no vc

me @ gradleware

toolmaker

keen on quality and team efficiency

strategic clients (LinkedIn)

conferences

talk

automation dogfood

gradle in large projects

gradle team

inside Gradle

~ 7 very distributed full time engineers

frequent, regular releases (~ 6 weeks)

10000+ automated tests

contains documentation and release notes

automationcritical for high performing teams

allows us to achieve high quality

continuous investment

persistent problem

everyone’s responsibility

our business

automation + dogfood

quality focus

lots of work to make Gradle greater

LinkedInGradle should ‘just scale’

challenges

scaling Gradle off limits

dealing with single build pipeline

adding value with each release

Gradle in very large projects

small project: <10 subprojects

medium project: <50 subrpojects

large project: <200 subprojects

very large project: 200+ subprojects

gigantic project: 2000 subprojects (real!)

dealing with large projects

don’t

ant

gradle and maven

use the wrapper

Igor’s story

larger builds take longer to troubleshoot

make the dev environment as consistent as possible

use the daemon

large builds inherently provide slower feedback

use all possible ways to quicken the feedback

daemon means snappier builds

even snappier in the future

use Gradle 1.7+

caching of dependency metadata

smarter cross-process synchronisation

use Gradle 1.8+

serialisation of the dependency results

Use Gradle 1.9+

daemon keeps task history in memory

use Gradle 1.10+

daemon caches the classloaders

keep using latest Gradle

more coming

daemon keeps configured model in memory

daemon finds out-of-date tasks in the background

parallel configuration

dogfoodingdogfooding automation every day

IDE/Editor

Automate the “import” process

Prerequisites are java & IDE but no Gradle (thanks to Wrapper)

Provide a consistent setup

Make it possible to run frequent tasks via the IDE

Testing

Unit

we are fond of tests, TDD and high coverage

groovy tests (spock) for java code

Integration testing

every integration test can be ran in different modes:

embedded (speed, fast dev cycles, easy debugging)

forking (slower but more realistic)

daemon (excellent stress test and coverage test for the daemon)

parallel (excellent stress test and coverage test for parallel feature)

Integration testing

cross version integration tests (backward compatibility)

run test against a set of different versions of a 3rd party tool (e.g.building scala, running jUnit tests)

run test against a set of Gradle versions

full suite VS recent version only

tooling api cross version tests (backward and forward compatibility)

consumer & provider

Testing

Cross platform

Distribution

Performance

Testable documentation

Automatically tested documentation

samples (in user guide or in distribution)

evaluation

running arbitrary tasks and comparison of output

using samples content for integration tests

build script snippets in the javadoc - evaluation (dsl reference, javadocs)

java code snippets in the javadoc - compilation attempt (javadocs)

slideware automation

Documentation

Automatically deployed documentation

User guide

DSL reference

API reference

Release notes

Code Quality

Ensure public API is documented

License headers

Cyclical package dependencies

Static analysis (Checkstyle & Codenarc)

Build pipeline

Runs on every push

Identical on both branches (master & release)

TeamCity

Pipeline structure

Static analysis

Quick, less accurate tests (small number of platforms)

Build production like distributions

Platform tests

Execution mode tests

Performance test

Promote

Reusing binaries

Production like binaries built at start of pipeline

CI server pushes binaries to downstream builds

Release cycleA cycle is ~ 6 weeks.

Move to release branch after ~ 4 weeks

Plan new release ~ 4 weeks

Promote RC ~ 5 weeks

Promote final (end)

Merge release branch back to master (final)

Promotion

Separate “build” for promotion

Automatically checks out specific revision

Programatically rebuilds Gradle

Imposes the version number

Triggered by 1 click @ CI server

Delivery

Build, smoke test

Decorate docs with Google Analytics JS

Upload to (some bits)repo.gradle.org

Upload dists and decorated docs to Amazon S3

Checkout website repo, update data, push

Trigger pull new docs

Smoke test delivered distributions

Send notification email to team

Finish with manual processes

Gradle.org

Data driven

Push deploy

Updated by non technical staff

Post “release” test

Defect tracking/planningThree levels:

forums.gradle.org -> entry point

issues.gradle.org -> acknowledged defects

Pivotal Labs -> team planning

Automated move/sync data between systems.

ForumsSome interesting automations/tweaks:

Markdown/syntax highlighting

Issue number linking

Documentation linking

News

Roadmap

Thanks!

gradle.org

gradleware.com

Questions?