Szczepan.faber.gradle
- 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
- 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
- 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