1 of 33

Ship every change to production!

​

  • How it is done in Mockito
  • How you can do it today with http://shipkit.org
  • How LinkedIn does it

​

​

  • JUG, Wroclaw, Poland
  • July 13st, 2017
  • Szczepan Faber (@mockitoguy), maker of Mockito, tech lead at LinkedIn Development Tools

​

2 of 33

Do you like making releases?

  • To include a feature in a release or not?
  • Am I ready to release or should I test more?
  • Oh no… release notes…

OVERHEAD

3 of 33

2008 - Mockito 1.0

  • Small library, small problems
  • Easy manual releases

4 of 33

2009-2013 Mockito popularity

  • More contributions, more use cases, more releases
  • Releases every 2 years because of…

5 of 33

How to build community?

  • Have great changelog
  • List contributors
  • Release frequently

​

(PS. Dan Ariely is not in software)

6 of 33

2014: Mockito & Continuous Delivery

  • Every merged pull request lands new version in Maven Central
  • Don’t ask about Mockito 2.x beta versions…

7 of 33

The bright side of CD in OSS

  • Productivity – zero release overhead
  • Happy users – get features faster
  • Faster debugging – quickly identify bad version (MTTR)
  • Sustainability – release & stay alive
  • No waste - no unreleased code
  • Quality – self-enforced craftsmanship of every change
  • Thriving, engaged community – contributions are released quickly

8 of 33

Feedback from community

  • Quality anxiety
  • What version to use?
  • Dependency Management cost

9 of 33

http://shipkit.org

  • Mockito’s own CD pipeline -> standalone Gradle plugins
  • Shipkit: toolkit for shipping it

10 of 33

Shipkit workflow

11 of 33

I have java code. How do I ship it?

12 of 33

13 of 33

3 steps to shipping in < 5 minutes

14 of 33

New Bintray repo is 1 click away!

15 of 33

Set up Travis CI in seconds!

16 of 33

Travis keeps the secrets safe

  • Also very easy to configure!

17 of 33

Core features of Shipkit

  • Publishing to Bintray and Central
  • Version bumps
  • Safe handling of private keys
  • Automated release notes
  • Listing contributors
  • Avoiding unnecessary releases

​

18 of 33

Release Notes

19 of 33

Release Notes

20 of 33

Release Notes

releaseNotes.labelMapping = [

'java-9' : "Java 9 support",

'java-8' : "Java 8 support",

'new feature' : "New features",

'bug' : "Bugfixes",

'improvement' : "Improvements",

'docs' : 'Documentation'

]

​

21 of 33

Release Notes

​

  • Task: updateReleaseNotes
    • preview notes:�gradlew updateReleaseNotes -Ppreview
    • update notes file:�gradlew updateReleaseNotes

22 of 33

Pom file

  • Task: generatePomFileForJavaLibraryPublication
  • Automatically include all contributors

23 of 33

When a new version is published?

Task: assertReleaseNeeded (ciReleasePrepare)

  • Skip if SKIP_RELEASE env var is present
  • Skip if commit message contains [ci skip-release] text
  • Skip if we are building a pull request (TRAVIS_PULL_REQUEST env var)
  • Skip if branch doesn’t match “master|release/.+” (e.g. master, release/2.x)
  • Skip if there are no changes in the production code

24 of 33

Avoiding unnecessary releases

  • Some changes don’t change the binaries (README.md, tests, ...)
  • Task comparePublications
    • Download a previous published version
    • Compare source jar and the pom file

25 of 33

Works with

26 of 33

Plans & goals

  • Simple, easy to use, smart defaults
  • Release notes templating
  • Integrating with services other than GitHub, Bintray etc.
  • Publishing to Maven Central, without Bintray
  • Automated E2E and A/B tests with dependers
  • Shipkit for Gradle Plugin authors - partnership with Gradle OSS team
  • GitHub Releases

​

​

​

27 of 33

Do you want to join our team?

28 of 33

Continuous Delivery in the enterprise

  • Rapid innovation
  • Competitive advantage
  • Productivity
  • Happy users
  • Faster debugging
  • Sustainability
  • No unreleased code
  • Quality

29 of 33

3x3 at LinkedIn

  • 3 hours max time from commit to production
  • 3 releases per day

30 of 33

Continuous delivery is hard!

(what do we do if something is hard?)

  • Flaky test is worse than no test
  • Production-grade tests and infrastructure
  • Open Source test frameworks too slow
  • Need for speed – going parallel and distributed
  • Master branch always green

31 of 33

Pushing quality - commit to production @LI

  1. Code change
  2. Code review
  3. Pre/post push validation
  4. Depender testing
  5. New version
  6. Staging
  7. Canary
  8. Ramp-up features
  9. Remove experiment

32 of 33

3x3 & engineering culture @LI

  • Engineering culture shift
  • It’s not about technology (but it plays a role)
  • Read more on LinkedIn eng blog

33 of 33

Thank you! Questions?�Ship every day production!

​

Wroclaw JUG

2017-07-13, Poland

  • Productivity
  • Happy users
  • Faster debugging
  • Sustainability
  • No unreleased code
  • Quality
  • Rapid innovation

Mockito’s journey to continuous delivery 2008-2017 - Szczepan

http://shipkit.org

Toolkit for shipping it used by Mockito

Est. 2017. Join us!

Continuous delivery at LinkedIn, by Szczepan:

  • 3x3 – 3 hours commit to production, 3 releases per day
  • Commit-to-production pipeline

Development Tools @LI is hiring!