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

1. Continuous Delivery for Open Source projects
Marcin Zajączkowski

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. 2 interesting companies

4. Agenda
issues with manual releasing
prerequisites
vision
implementation steps
available solutions
CDeliveryBoy
best practices

5. Presentation goal
Continuous Delivery in FOSS projects
is not science fiction

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. 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. 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. 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. 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. 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. (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. 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. CD - bump version number
increase project version number locally
make release commit
create version tag on release commit

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. CD - build & upload artifacts
build artifacts
sign artifacts
upload artifacts to artifacts repository (Nexus)

17. CD - push changes in Git
push release commit
push release tag

18. CD - promote artifacts
promote artifacts to Maven Central
via Nexus REST API

19. CD - promote artifacts
promote artifacts to Maven Central
via Nexus REST API
artifacts available for everyone in a few minutes

20. CD - post-publish operations
generate release notes
close/create milestone
send notifications
...

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. 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. 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. 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. 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. CDeliveryBoy in action
Let's release something

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. 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. 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. Alternatives

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. 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. 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. 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. Thank you!
(and remember about feedback)
Marcin Zajączkowski
http://blog.solidsoft.info/
@SolidSoftBlog
m.zajaczkowski@gmail.com

36. Questions?
(and remember about feedback)
Marcin Zajączkowski
http://blog.solidsoft.info/
@SolidSoftBlog
m.zajaczkowski@gmail.com