Continuous Delivery with Jenkins at ZeroTurnaround

Slides from my talk at http://www.meetup.com/St-Petersburg-Jenkins-Meetup/events/229259353/

Transcript

1. CD@ZT
2. OURPRODUCT • XRebel Hub (now in public beta!) collects performance metrics using Java agents in test environments • APM (Application Performance Management) service, but for pre-prod • Real-time overview of performance changes • Good old XRebel under the hood @bsideup
3. @bsideup
4. @bsideup
5. WEDELIVER @bsideup • Front-End - SPA, hosted as static site, consumes REST APIs • Auth & management API service • Analytics service • (Upcoming) Collector service (lambda architecture) • Java agent
6. But we started with…
7. Monolith!
8. SOA, micro-
 services, SPA Monolith! But… Hipsters say….
9. No customers
 = No worries!
10. One CI job for everything!
11. Monorepo!
12. Commits to master!
13. Single delivery pipeline!
14. But then…
15. MONOREPOFAIL • More merge commits than real ones • Hard to track changes. Partial solution - Jenkins’s subdirectory polling • Java build tools vs JavaScript build tools @bsideup
16. DELIVERYFAIL • Can’t deliver a quickfix on front-end without delivering back-end • Rollback of back-end will affect front-end • Long-running releases because scope of changes usually was big - not good for Continuous Delivery @bsideup
17. SOA
18. MULTIPLEPIPELINES • Everything is a service • Front-end consumes them as REST APIs • Each deliverable artifact has it’s own repo, Jenkins Job DSL, delivery pipeline • Artifacts are stored on Jenkins as build artifacts • At most one non-production build on staging (aka delivery gate) • Once change in master it must be delivered ASAP @bsideup
19. SEPARATEFRONTEND • Jenkins S3 plugin for deployment • Protractor tests with Selenium and Xvfb in a container (Docker) @bsideup
20. BACKENDDELIVERY • All endpoints are covered with integration tests • We run integration tests during the CI job • environment prepared with Docker Compose as a shell step and runs on Jenkins @bsideup
21. PULLREQUESTS • Each change - is a pull request • Should be approved by both code reviewer and QA • BitBucket pull request builder plugin for Jenkins rules! Run tests before you merge and see status in PR’s UI: @bsideup
22. SYSTEMTESTS • We’re running selenium tests on Jenkins inside a container with Chromium and Xvfb • during the test, it starts many Tomcat instances with our Java Agent attached, verifies that our system works fine - all with one simple Jenkins job @bsideup
23. LESSONSLEARNED • Visualize your pipelines (i.e. delivery pipeline plugin) • Automate your tests, but keep QA as a gate keeper (i.e. use Jenkins manual step) • Test all stages - pull request builders, integration and system tests • Make use of notifications (i.e. Slack plugin) • Configure jobs as a code - easier to split things and create more micro- services • Create clean environments for tests (i.e. with Docker) @bsideup
24. FUTUREPLANS • More micro–services, using the same job definitions • Migrate to Pipeline plugin (aka workflow, aka Jenkins 2.0) • Integrate multi-branch plugin to get earlier feedback about the commits (instead of pull request builders) • Release our plugin for better pipelines visualization (aka Delivery Center) • Deliver CloudFormation templates with Jenkins pipeline • Deliver Logstash reindexers with Jenkins as pipeline (plugin?) @bsideup
25. THANKYOU!