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.

Marcin Zajączkowski

January 09, 2015
Tweet

More Decks by Marcin Zajączkowski

Other Decks in Technology

Transcript

  1. Agenda • Issues with manual releasing • Releasing steps •

    New releasing mechanism in micro-infra projects 2
  2. • 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
  3. • 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
  4. • 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
  5. • 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
  6. 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
  7. • 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
  8. • Build artifacts (jar, source jar, war, …) • Upload

    artifacts to Bintray 2. Upload artifacts to Bintray 10
  9. • 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
  10. 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
  11. (...) 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
  12. - 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
  13. • 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
  14. • merge 5 projects into one umbrella project ◦ unified

    versioning ◦ consistent changelog ◦ easier and faster to release ◦ less confusing for newcomers Internal changes 18
  15. • 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
  16. • 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
  17. • 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
  18. • Automatic CHANGELOG.md generator • Optional automatic releases after every

    commit ◦ If requested • Support for other CI servers ◦ If requested Distant future 23