Szczepan.faber.gradle

519 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
519
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Szczepan.faber.gradle

  1. 1. Gradlebuilding great tool
  2. 2. me szczepan faber lives in krakow/poland lead at Mockito core dev at Gradle soccer junkie (idzie, idzie, idzie, …)
  3. 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. 4. gradleware looks after Gradle offers consulting no vc
  5. 5. me @ gradleware toolmaker keen on quality and team efficiency strategic clients (LinkedIn) conferences
  6. 6. talk automation dogfood gradle in large projects gradle team
  7. 7. inside Gradle ~ 7 very distributed full time engineers frequent, regular releases (~ 6 weeks) 10000+ automated tests contains documentation and release notes
  8. 8. automation critical for high performing teams allows us to achieve high quality continuous investment persistent problem everyone’s responsibility
  9. 9. our business automation + dogfood quality focus lots of work to make Gradle greater
  10. 10. LinkedInGradle should ‘just scale’
  11. 11. challenges scaling Gradle off limits dealing with single build pipeline adding value with each release
  12. 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. 13. dealing with large projects don’t ant gradle and maven
  14. 14. use the wrapper Igor’s story larger builds take longer to troubleshoot make the dev environment as consistent as possible
  15. 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. 16. use Gradle 1.7+ caching of dependency metadata smarter cross-process synchronisation
  17. 17. use Gradle 1.8+ serialisation of the dependency results
  18. 18. Use Gradle 1.9+ daemon keeps task history in memory
  19. 19. use Gradle 1.10+ daemon caches the classloaders
  20. 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. 21. dogfoodingdogfooding automation every day
  22. 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. 23. Testing Unit we are fond of tests, TDD and high coverage groovy tests (spock) for java code
  24. 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. 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. 26. Testing Cross platform Distribution Performance
  27. 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. 28. Documentation Automatically deployed documentation User guide DSL reference API reference Release notes
  29. 29. Code Quality Ensure public API is documented License headers Cyclical package dependencies Static analysis (Checkstyle & Codenarc)
  30. 30. Build pipeline Runs on every push Identical on both branches (master & release) TeamCity
  31. 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. 32. Reusing binaries Production like binaries built at start of pipeline CI server pushes binaries to downstream builds
  33. 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. 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. 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. 36. Gradle.org Data driven Push deploy Updated by non technical staff Post “release” test
  37. 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. 38. Forums Some interesting automations/tweaks: Markdown/syntax highlighting Issue number linking Documentation linking News Roadmap
  39. 39. Thanks! gradle.org gradleware.com Questions?

×