1. Gradlebuilding great tool

2. me
szczepan faber
lives in krakow/poland
lead at Mockito
core dev at Gradle
soccer junkie (idzie, idzie, idzie, …)

3. gradle
what 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

4. gradleware
looks after Gradle
offers consulting
no vc

5. me @ gradleware
toolmaker
keen on quality and team efficiency
strategic clients (LinkedIn)
conferences

6. talk
automation dogfood
gradle in large projects
gradle team

7. inside Gradle
~ 7 very distributed full time engineers
frequent, regular releases (~ 6 weeks)
10000+ automated tests
contains documentation and release notes

8. automation
critical for high performing teams
allows us to achieve high quality
continuous investment
persistent problem
everyone’s responsibility

9. our business
automation + dogfood
quality focus
lots of work to make Gradle greater

10. LinkedInGradle should ‘just scale’

11. challenges
scaling Gradle off limits
dealing with single build pipeline
adding value with each release

12. 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!)

13. dealing with large projects
don’t
ant
gradle and maven

14. use the wrapper
Igor’s story
larger builds take longer to troubleshoot
make the dev environment as consistent as possible

15. 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

16. use Gradle 1.7+
caching of dependency metadata
smarter cross-process synchronisation

17. use Gradle 1.8+
serialisation of the dependency results

18. Use Gradle 1.9+
daemon keeps task history in memory

19. use Gradle 1.10+
daemon caches the classloaders

20. keep using latest Gradle
more coming
daemon keeps configured model in memory
daemon finds out-of-date tasks in the background
parallel configuration

21. dogfoodingdogfooding automation every day

22. 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

23. Testing
Unit
we are fond of tests, TDD and high coverage
groovy tests (spock) for java code

24. 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)

25. 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

26. Testing
Cross platform
Distribution
Performance

27. 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

28. Documentation
Automatically deployed documentation
User guide
DSL reference
API reference
Release notes

29. Code Quality
Ensure public API is documented
License headers
Cyclical package dependencies
Static analysis (Checkstyle & Codenarc)

30. Build pipeline
Runs on every push
Identical on both branches (master & release)
TeamCity

31. Pipeline structure
Static analysis
Quick, less accurate tests (small number of platforms)
Build production like distributions
Platform tests
Execution mode tests
Performance test
Promote

32. Reusing binaries
Production like binaries built at start of pipeline
CI server pushes binaries to downstream builds

33. Release cycle
A 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)

34. Promotion
Separate “build” for promotion
Automatically checks out specific revision
Programatically rebuilds Gradle
Imposes the version number
Triggered by 1 click @ CI server

35. 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

36. Gradle.org
Data driven
Push deploy
Updated by non technical staff
Post “release” test

37. Defect tracking/planning
Three levels:
forums.gradle.org -> entry point
issues.gradle.org -> acknowledged defects
Pivotal Labs -> team planning
Automated move/sync data between systems.

38. Forums
Some interesting automations/tweaks:
Markdown/syntax highlighting
Issue number linking
Documentation linking
News
Roadmap

39. Thanks!
gradle.org
gradleware.com
Questions?