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.

DevOps Fest 2020. Kohsuke Kawaguchi. GitOps, Jenkins X & the Future of CI/CD


Published on

CI/CD process has been something your DevOps engineer purpose-built for your team. But with Kubernetes & cloud-native, that’s becoming “legacy.” The rising level of platform abstraction allows all the good practices that the industry has developed over time to be integrated, hidden, and simplified behind just one practice called “GitOps.” That simplified world is what Jenkins X enables.
We will discuss GitOps, Jenkins X, and how that combination drastically simplifies cloud-native web app development. You’ll understand why traditional DevOps is not suitable in a Kubernetes and cloud-native world, explore GitOps principles and discover how they facilitate high-velocity app development.
And finally, Kohsuke will make a fool of himself by talking about the future — now that Jenkins X simplifies the CD process, where is the next frontier?

Published in: Education
  • Be the first to comment

DevOps Fest 2020. Kohsuke Kawaguchi. GitOps, Jenkins X & the Future of CI/CD

  1. 1. GitOps, Jenkins X & Future of CI/CD Kohsuke Kawaguchi | Co-CEO, Launchable, Inc. | @kohsukekawa
  2. 2. DORA State of DevOps Reports
  3. 3. “software delivery is an exercise in continuous improvement, and our research shows that year over year the best keep getting better, and those who fail to improve fall further and further behind.” - Nicole Forsgren
  4. 4. Building and scaling high performance technology organisations
  5. 5. • Common platform in all clouds • AWS, Azure, GCP • OpenShift, CloudFoundry • Functionalities • Cluster scheduler • Service discovery • Load balancer • Extensibility New “Cloud Operating System” is here
  6. 6. DevOps is the new legacy
  7. 7. So what is important?
  8. 8. GitOps
  9. 9. What? Source:
  10. 10. Why? • Transparency without sacrificing auditability & access control • How/who to get changes in • What has happened • Tools agnostic – works with any ”Infrastructure as Code,” not just K8s
  11. 11. Why? • Promote higher abstraction and reuse • Review/test before you merge • Trivial roll back, change detection, etc through familiar workflows of Git/GitHub
  12. 12. You can have fun tinkering…
  13. 13. Or you can just get productive
  14. 14. Jenkins X vision • Figure out the best practice of how to CD cloud native apps • Not just build, test, but reviewing, promotion, changelog, collaboration, etc. • Integrate best of the bleed software in this ecosystem to achieve it • Democratize it by building a pleasant CLI that represents high-level steps • Be opinionated on how to do things • Kubernetes is a means to the end
  15. 15. Image:
  16. 16. Development Flow We Preach
  17. 17. More Best practice we preach • Use cloud to develop, keep your laptop for what it needs to do • Keep master always releasable • Deploy often and in small increments • Inform other people about where changes are
  18. 18. Best Practices That Are “Boring”
  19. 19. Integrate best of the bleed software in this ecosystem to achieve it
  20. 20. MultiCloud Support: jx create cluster
  21. 21. • brew tap jenkins-x/jx • brew install jx • jx create cluster Let’s get going
  22. 22. • You got all that tools, preconfigured properly • Jenkins, with elastic build agents to build containers • Artifact repository to speed up your builds • Monocular to catalog Helm charts • You got staging & production environments • For all your future apps to be onboarded to Jenkins X What just happened?
  23. 23. • Create a new project • jx create spring • Make your existing app work in Jenkins X • jx import Prepare your app
  24. 24. • Source code • Wiring for build, deploy, & CD • Jenkinsfile, Dockerfile, helm chart, … • All services configured for you • Repo on GitHub, webhook to Jenkins, Jenkins jobs • Initial release & all running in staging What just happened?
  25. 25. • Work locally on a change • Create a PR on GitHub • Have the change reviewed & merged Let’s work on a change
  26. 26. • Your PR gets automatically built & tested • App deployed to a PR specific ‘preview environment’ • Allows stakeholders to interact with the app • Click a link in PR to see it • (Then you merge your change) • New master gets automatically built & tested • New release gets created with changelog What just happened?
  27. 27. • jx promote --version v0.0.3 --env production • Go to GitHub and merge ‘deployment’ PR • (v0.0.3 appears in production) Let’s promote a release to production
  28. 28. Future of CI/CD
  29. 29. • Defend stability through depth, not just tests GitOps is necessary, but not sufficient for higher velocity
  30. 30. • Feature Flags • Circuit Breaker • Canary Deployment • Better Observability How do you defend in depth?
  31. 31. Leverage Production Traffic • Because there’s nothing like production • Traffic mirroring • A/B testing
  32. 32. • Situation • You are the DevOps team of a BigCo • Massive modularized codebase with web of dependencies • Big, time consuming tests around them • Questions • I want to cut cost & time of the software delivery process Smarter testing
  33. 33. Step 1: Dependency Analysis
  34. 34. • ML model predicts useful subset to run • Based on information about changes • Of 105 changes/mo, 1% is used to train the model • Impact • Only a third of tests are selected • Misses just 0.1% of broken changes • AWS cost is cut by half 36 Step 2: Predictive Test Selection
  35. 35. • Situation • You are the SRE team in a BigCo • You oversee 100s of apps • ~1 deployment/app/day • Questions • Can we flag risky deployments beforehand? 37 Deployment Risk Prediction
  36. 36. • Train model • With 40,000 deployments of which 100 are failures • Attributes: app names, commit messages, … • Impact • Predict 99% of failures • 5% false alarm rate 38 What they have done
  37. 37. • Learning • Most outages are estimated as “low risk” by developers • Most outages had short time span till approval • Long-maintained code is more risky • Imagine what you can do with this! • Require somebody be on call • Restrict window of deployment 39 What they have done
  38. 38. Where This Takes Us
  39. 39. • Every organization is trying to get better at software delivery • Kubernetes is an enabling technology but it can be a detractor • What’s important is DX, which is GitOps • Jenkins X brings that for K8s without you rolling your own which becomes legacy • CI/CD is continuously evolving, so is Jenkins Wrap Up
  40. 40. Thank You!