Inside The Elastic Stack - Testing and Releasing a Well Known Open Source Stack

Inside The Elastic Stack - Testing and Releasing a Well Known Open Source Stack

Maintaining a well known open source stack is no easy task. Despite fixing bugs and adding features, releases need to be aligned among products and each product needs to be tested on its own. This talk starts at the lowest level of Elasticsearch, explaining how we run unit tests, moves up to integration tests, packaging tests, backwards compatibility tests, performance tests, including commercial extensions in testing phases - all of this on different operating systems and JVM versions. Attendees will get to know how our CI looks and how all of our products (Elasticsearch, Logstash, Kibana, Beats and all of its commercial extensions) are released at the same moment in order to ease the upgrade process for our end users.

D5cd900453405c985e97c63e9f92061d?s=128

Alexander Reelsen

April 19, 2018
Tweet

Transcript

  1. Alexander Reelsen @spinscale alex@elastic.co Inside the Elastic Stack Testing &

    releasing a well known Open Source stack
  2. Alexander Reelsen @spinscale alex@elastic.co Inside the Elastic Stack Testing &

    releasing a well known Open Source stack
  3. Alexander Reelsen @spinscale alex@elastic.co Inside the Elastic Stack Testing &

    releasing a well known Open Source stack
  4. !4 Agenda One slide every 30 seconds is ok, right?

    Introduction 1 CI 3 Preparing & testing a release 4 Release 5 Elasticsearch testing 2 2 3 4 5
  5. !5 Agenda One slide every 30 seconds is ok, right?

    Introduction 1 CI 3 Preparing & testing a release 4 Release 5 Elasticsearch testing 2
  6. !6 What is the Elastic Stack?

  7. !7 Welcome to the Zoo! • Elasticsearch: Java • Logstash:

    JRuby + Java • Beats: Go • Kibana: Javascript on node.js • APM: server: go, instrumentation agents: javascript, ruby, go, java, python • Commercial: C++, Scala, Ruby, Go, all of the above • Tooling: Perl, python, node, ruby, gradle, typescript • Clients: Ruby, PHP, Perl, python, .NET, Java, Go • Infra: lambda, k8s, vault, ansible, terraform, docker, jenkins/jjb
  8. !8 Jun 9, 2015 1.6 Jul 16, 2015 1.7 Feb

    19, 2015 4.0 Jun 10, 2015 4.1 May 14th, 2015 1.5 May 27th, 2015 1.0 Beta 1 July 13th, 2015 1.0 Beta 2 Sept 4 th, 2015 1.0 Beta 3 May 23, 2015 1.5 Nov 5, 2014 1.4 It’s complicated es kibana ls beats
  9. None
  10. !10 Agenda One slide every 30 seconds is ok, right?

    Introduction 1 CI 3 Preparing & testing a release 4 Release 5 Elasticsearch testing 2 2 1
  11. !11 •Unit Tests •REST Tests •Packaging Tests •Documentation Tests •BWC

    tests •Performance Tests Tests everywhere!
  12. !12 Unit Tests

  13. !13 Unit Tests

  14. !14 Unit Tests

  15. !15 Integration Tests

  16. !16 REST tests

  17. !17 REST tests

  18. !18 Packaging Tests

  19. !19 Packaging Tests via BATS

  20. !20 Documentation tests

  21. !21 Documentation tests

  22. !22 Smoke tests

  23. !23 BWC tests

  24. !24 QA tests

  25. !25 Agenda One slide every 30 seconds is ok, right?

    Introduction 1 CI 3 Preparing & testing a release 4 Release 5 Elasticsearch testing 2 1 3
  26. !26

  27. !27

  28. !28

  29. !29

  30. !30

  31. !31

  32. !32 Moar testing • 1000+ builds ES per day across

    all branches • Testing of pull requests • Testing on different operating systems • Testing on different JVMs • Testing with different garbage collectors • Testing of feature branches • Dedicated jenkins cluster for x-pack as well as other tools • Docs CI: Ensure cross reference links work • Test triage, developers take care of build failures
  33. !33 Manual Testing • Small team of dedicated testers, working

    with developers • Exploratory testing • UI testing • Cross product testing • Integration testing with products outside of the stack
  34. !34 Agenda One slide every 30 seconds is ok, right?

    Introduction 1 CI 3 Preparing & testing a release 4 Release 5 Elasticsearch testing 2 4 1
  35. !35

  36. !36

  37. !37 Releasing - One project to build them all! •

    Idea: Every engineer should be able to build a release candidate • Single repo with Vagrantfile and gradle build • Requirements: Vagrant (+ winrm), VirtualBox, gradle • Vagrant image installs the technology zoo! • Builds projects, creates package repositories (+ signing) and uploads to S3 bucket, uploads to sonatype staging repo • Result: Final immutable artifacts, which are ready to be released
  38. !38 Agenda One slide every 30 seconds is ok, right?

    Introduction 1 CI 3 Preparing & testing a release 4 Release 5 Elasticsearch testing 2 5 1
  39. !39 Releasing gradle release

  40. !40 Releasing • Uploading/building documentation • Publish blog posts •

    Update website download links • Forum posts • Post release work (internal version updates in ES)
  41. !41

  42. !42

  43. !43 Summary • Automate your releases with immutable releasable artifacts!

    • Do it as early as possible! • Ensure everyone can do a release! • Non technical aspects are incredibly harder to automate! • Does this work for you? No idea!
  44. Thanks for listening! Questions? @spinscale alex@elastic.co

  45. !45 Links • https://benchmarks.elastic.co • https://elasticsearch-ci.elastic.co/ • https://beats-ci.elastic.co/ • https://kibana-ci.elastic.co/

    • https://logstash-ci.elastic.co/ • https://github.com/elastic/rally • https://speakerdeck.com/elasticsearch/oscon-scaling-a-distributed- engineering-team-from-50-250
  46. Thanks for listening! Questions? @spinscale alex@elastic.co