Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JDD 2016 - Marcin Zajaczkowski - Cd for open source

104 views

Published on

Masz projekt, w którym wydawanie nowej wersji wymaga ręcznego wykonywania serii komend, jest błędogenne i po prostu nudne? A może chciałbyś zacząć nowy projekt open source z Continuous Delivery, ale przeraża Cię konfiguracja, którą trzeba wykonać, aby wyda wersja byłą w wygodny sposób dostępna dla innych? W czasie prezentacji pokażę w jaki sposób w ciągu 15 minut (*) możesz stworzyć szkielet swojego nowego projektu open source z działającym mechanizmem automatycznego wydawania wersji do Maven Central po (każdym) commicie. Będziemy operować na stosie opartym o Java/Groovy/Scala/Kotlin, Gradle, GitHub, Travis i Maven Central. Jeżeli Twoja istniejąca aplikacja używa podobnych rozwiązań wdrożenie nowego mechanizmu powinno zająć niewiele więcej czasu. Continuous Delivery jest trudne z (przynajmniej) dwóch powodów. 1. Projekt musi być tak dobrze napisany i przetestowany, aby nie obawiać się wydać wersji w dowolnej chwili bazując jedynie na wyniku testów automatycznych (bez ręcznego testowania). 2. Czynności związane z wydaniem wersji (zarządzanie numeracją wersji, testowaniem, budowanie paczek, tagowanie zmian, czy wysyłka do publicznego repozytorium paczek) zazwyczaj nie są trywialne do automatyzacji. W dbaniu o jakość i automatyczne testowanie naszego rozwiązania nikt nas nie wyręczy. Jednak mechanizmy do automatycznego wdrażania to przede wszystkim infrastruktura i tu ponowne "wymyślanie koła" (szczególnie w przypadku bibliotek open source z prostym release workflow) najczęściej nie jest najbardziej optymalnym rozwiązaniem. Dowiedź się, jak wykorzystać istniejące rozwiązania - szybko i prosto

Published in: Technology
  • Be the first to comment

  • Be the first to like this

JDD 2016 - Marcin Zajaczkowski - Cd for open source

  1. 1. Continuous Delivery for Open Source projects Marcin Zajączkowski
  2. 2. About me Areas of expertise Automatic Testing / TDD Software Craftsmanship / Code Quality Concurrency / Parallel Computing / Reactive Systems Deployment Automation / Continuous Delivery FOSS projects author and contributor, blogger, trainer CTO of small software house - Codearte targeted at clients who care about the quality
  3. 3. 2 interesting companies
  4. 4. Agenda issues with manual releasing prerequisites vision implementation steps available solutions CDeliveryBoy best practices
  5. 5. Presentation goal Continuous Delivery in FOSS projects is not science fiction
  6. 6. Manual releasing - issues local workstation configuration magical incantations, necessarily in correct order not repeatable and not reliable longer feedback loop (developer's) time consuming boring...
  7. 7. Continuous Delivery (in general) Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery. Based on Wikipedia
  8. 8. Continuous Delivery (in general - points) every build is a release candidate can be possibly deployed to production faster and more often releases shorter time to market (TTM) reduced risk of delivering changes omnipresent automation repeatable builds & deployments high confidence in automatic tests unit, integration, acceptance, ...
  9. 9. Continuous Delivery (in FOSS project) usually library/framework/tool much simpler release pipeline no deployment to different environments no database migration no ... indirect deployment to production end applications should be tested independently
  10. 10. Prerequisites for CD automatized builds on CI server high code quality with strong set of automatic tests no manual testing before release preferably with integration/acceptance tests
  11. 11. Prerequisites for CD automatized builds on CI server high code quality with strong set of automatic tests no manual testing before release preferably with integration/acceptance tests when fulfilled "only" infrastructure release part remains to add
  12. 12. (My) Vision everything after commit done automatically on (public) CI server artifacts immediately available in Maven Central all release logic hidden in build tool plugin shell scripting reduced to minimum convention over configuration works by default in most cases on demand releasing triggered by command in commit message
  13. 13. CD - steps - bird's-eye view bump version number in local Git repository build, sign and upload artifacts to artifacts repository (Nexus) push changes to GitHub promote/release uploaded artifacts to Maven Central post-publish operations
  14. 14. CD - bump version number increase project version number locally make release commit create version tag on release commit
  15. 15. CD - bump version number increase project version number locally make release commit create version tag on release commit Git tags - ultimate information about current version
  16. 16. CD - build & upload artifacts build artifacts sign artifacts upload artifacts to artifacts repository (Nexus)
  17. 17. CD - push changes in Git push release commit push release tag
  18. 18. CD - promote artifacts promote artifacts to Maven Central via Nexus REST API
  19. 19. CD - promote artifacts promote artifacts to Maven Central via Nexus REST API artifacts available for everyone in a few minutes
  20. 20. CD - post-publish operations generate release notes close/create milestone send notifications ...
  21. 21. Self motivation maintainer of a bunch of FOSS projects non trivial release configuration versioning, tagging, artifacts promotion, ... even for manual releasing hard to maintain across projects no suitable CD solution on the market every committer should be able to perform release big fan of automation especially of regularly performed operations
  22. 22. C(ontinuous)DeliveryBoy comprehensive mechanism for CD in FOSS projects with clearly defined workflow/conventions Gradle plugin with sensible defaults GitHub, Travis and Maven Central supported out-of-box JVM language agnostic (Java, Gradle, Scala, Kotlin, ...) specialized tools used internally for specific activities Axion plugin, Nexus plugin, Nexus Staging plugin best to setup new project can be also applied on existing Gradle projects inspired by CD mechanism in Mockito by Szczepan Faber
  23. 23. CDeliveryBoy - sample configuration cDeliveryBoy { ciType = "travis" git { releaseBranch = "release" user = "Heniek CI" email = "heniek-ci@coolfoss.io" } trigger { releaseOnDemand = true onDemandReleaseTriggerCommand = "GOGOGO!" } nexus { autoPromote = true packageGroup = "io.coolfoss" } tasks { buildProject = ["fancyBuild"] } }
  24. 24. CDeliveryBoy - triggering release by default new snapshot version is produced "magic" command in commit message to make a release git commit -m "Trigger release" -m "[#DO_RELEASE]" --allow-empty
  25. 25. CDeliveryBoy - triggering release by default new snapshot version is produced "magic" command in commit message to make a release git commit -m "Trigger release" -m "[#DO_RELEASE]" --allow-empty can be also added from GitHub UI when merging PR new release possible using mobile phone useful when on holidays :)
  26. 26. CDeliveryBoy in action Let's release something
  27. 27. Project status (as of X 2016) basic scenarios work self-released under heavy development things may change - use with caution :) https://github.com/szpak/CDeliveryBoy
  28. 28. Limitations/drawbacks (as of X 2016) still a few manual steps at the beginning especially for the first project some errors during release has to be resolved/reverted manually Axion plugin doesn't support setting custom Git refspec direct Git execution as temporary workaround no automatic acceptance tests in Travis-like environment
  29. 29. Possible enhancements (as of X 2016) next version number defined in commit message rollback steps whenever possible more flexible list of steps definition automatic release notes generation based on closed issues/pull requests new preconfigured project bootstrapping with Lazybones?
  30. 30. Alternatives
  31. 31. Alternatives - homemade scripts with Gradle - (almost) the sky is the limit :) a lot of plugins available to glue together Axion plugin, gradle-git plugin, Nexus plugin, Nexus Staging plugin, ... can learn much about Gradle, Git and releasing :)
  32. 32. Alternatives - Bintray take care of artifacts upload Bintray/JCenter by default can optionally sync to Maven Central still have to handle versioning and Git operations manually micro-common-release can be used to glue everything together yet, it is rather a set of scripts than reusable component
  33. 33. Best practices (for FOSS projects) new version release only when appropriate releasing every single commit can be too often e.g. Mockito 2.0 lesson learned - 100+ beta versions effective integration/acceptance tests to prevent regressions
  34. 34. Summary fast feedback loop not released feature is not very useful code quality & strong test harness matter in general CD in your FOSS project might be doable/feasible effortless (when implemented :) ) beneficial
  35. 35. Thank you! (and remember about feedback) Marcin Zajączkowski http://blog.solidsoft.info/ @SolidSoftBlog m.zajaczkowski@gmail.com
  36. 36. Questions? (and remember about feedback) Marcin Zajączkowski http://blog.solidsoft.info/ @SolidSoftBlog m.zajaczkowski@gmail.com

×