Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Automatic releases in micro-infra-spring (with Gradle, Git, Bintray and Travis)

Automatic releases in micro-infra-spring (with Gradle, Git, Bintray and Travis)

Slides from my presentation about automatic releases with Gradle, Git, Bintray and Travis implemented in the micro-infra-spring project.

micro-infra-spring (https://github.com/4finance/micro-infra-spring) is an open source library created to speed up development of Spring Boot based microservices and to make their deployment and maintenance as simply as possible.

220d0825b07706221aeae4751057ede8?s=128

Marcin Zajączkowski

January 09, 2015
Tweet

Transcript

  1. Automatic releases in micro-infra (with Gradle, Git, Bintray and Travis)

    Marcin Zajączkowski sTools team 2015-01-09
  2. Agenda • Issues with manual releasing • Releasing steps •

    New releasing mechanism in micro-infra projects 2
  3. • Required configured workstation • Required knowledge of Voodoo magic

    • Not repeatable and not reliable • Consumed developer’s time • Longer feedback loop • Boring... Manual releasing - issues 3
  4. • 5 separate Git/Gradle projects ◦ released separately ◦ depended

    on each other ◦ with specific release order ◦ error-prone-bumping dependant projects-version in every build.gradle ◦ hard to determine real changelog in top-level project ◦ hard to do a few complete releases a day micro-infra - additional issues 4
  5. • Everything after commit done automatically on CI server (Travis)

    • Artifacts immediately available for everyone (Bintray/JCenter) • On demand releasing controlled by command embedded into commit message • Power of Gradle under the hood Initial assumptions for micro-infra 5
  6. • Managing versions across the projects • Triggering release of

    the higher level project(s) ◦ Usually all higher level modules should also be released Predicted problems 6
  7. 7 Live demo - part 1

  8. 1. Bump version number in local Git repository 2. Build

    and upload artifacts to Bintray 3. Push changes to GitHub 4. Publish in Bintray previously uploaded artifacts (make them available in JCenter) Release process - steps 8
  9. • Bump project version number • Make release commit •

    Create version tag on created commit • Git tags - ultimate source of current version • Implemented with Axion release plugin 1. Bump version in local repo 9
  10. • Build artifacts (jar, source jar, war, …) • Upload

    artifacts to Bintray 2. Upload artifacts to Bintray 10
  11. • Push release commit • Push release tag 3. Push

    changes to GitHub 11
  12. • Publish artifacts to jCenter • Make them available to

    the world 4. Publish artifacts 12
  13. • New micro-common-release project ◦ Release mechanism ◦ Default versioning

    and publishing configuration ◦ Available at: https://github.com/4finance/micro- common-release ◦ Based on Continuous Delivery conception by Szczepan Faber Implementation 13
  14. buildscript { repositories { jcenter() } dependencies { classpath "com.ofg:micro-common-release:0.1.3"

    } dependencies { ant.unjar src: configurations.classpath.find { it.name.startsWith("micro-common-release") }, dest: 'build/release' } } (...) Configuration 14
  15. (...) apply from: 'build/release/gradle/version.gradle' scmVersion { tag { prefix =

    'my-proj' } } project.version = scmVersion.version apply plugin: 'groovy' //or 'java' apply from: 'build/release/gradle/publish.gradle' apply from: 'build/release/gradle/release.gradle' Configuration - continued 15
  16. - source build/release/gradle/setGitVariables.sh - ./gradlew release -Prelease.localOnly - ./gradlew check

    finalizeRelease publishUploadedArtifacts • Secure variables to handle credentials • Can be used together with build matrix ◦ Builds on different JVM versions Configuration - Travis 16
  17. • In the last commit of given feature ◦ With

    commit message ________________________________________________ [#132] New cool feature [#DO_RELEASE] ________________________________________________ • In separate triggering commit git commit -m “Trigger release” -m “[#DO_RELEASE]” Triggering release 17
  18. • merge 5 projects into one umbrella project ◦ unified

    versioning ◦ consistent changelog ◦ easier and faster to release ◦ less confusing for newcomers Internal changes 18
  19. • micro-infra releases done automatically on Travis ◦ With just

    [#DO_RELEASE] command in commit message git commit -m “Trigger release” -m “[#DO_RELEASE]” Current status 19
  20. Live demo - part 2 20

  21. • Every contributor can simply release new version when needed

    ◦ without any secret knowledge ◦ from any machine with GitHub access ◦ even from mobile phone (for @MGrzejszczak ;-) ) • Simplified build.gradle configuration • More time for developers to deliver business value ;-) Benefits 21
  22. • Automatic smoke testing before publishing to everyone • Use

    in all FOSS projects in 4F • Convert to separate Gradle plugin ◦ Easier to use in other projects - also outside 4F • Integrate with GitHub milestones mechanism Predictable future 22
  23. • Automatic CHANGELOG.md generator • Optional automatic releases after every

    commit ◦ If requested • Support for other CI servers ◦ If requested Distant future 23
  24. Q & A

  25. Feel free to create an issue: https://github.com/4finance/micro-common-release or contact me

    directly More questions?
  26. Marcin Zajączkowski m.zajaczkowski@gmail.com 2015-01-09 Thanks for listening