GitOps, Jenkins X &Future of CI/CD

GitOps, Jenkins X &
Future of CI/CD
Kohsuke Kawaguchi | CTO, CloudBees, Inc.
kkawaguchi@cloudbees.com | @kohsukekawa

2© 2019 CloudBees, Inc. All Rights Reserved.
DORA State
of DevOps
Reports

The Science of Lean
Software and DevOps
“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

Building and scaling high performance
technology organisations

• Common platform in all clouds
• AWS, Azure, GCP
• OpenShift, CloudFoundry
• Functionalities
• Cluster scheduler
• Service discovery
• Load balancer
• Extensibility
New “Cloud Operating System” is here

DevOps is the new legacy

So what is important?

What?
Source: https://www.weave.works/blog/what-is-gitops-really

• 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
• Promote higher abstraction and reuse
• Review/test before you merge
• Trivial roll back, change detection, etc through familiar workflows of Git/GitHub
Why?

You can have fun tinkering…

Or you can just get productive

• 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
Jenkins X vision

Image: https://flic.kr/p/smze69

Development Flow 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
More Best practice we preach

Best Practices That Are “Boring”

Integrate best of the bleed software in this ecosystem to achieve it

MultiCloud Support: jx create cluster

• brew tap jenkins-x/jx
• brew install jx
• jx create cluster
Let’s get going

• 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?

• Create a new project
• jx create spring
• Make your existing app work in Jenkins X
• jx import
Prepare your app

• 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?

• Work locally on a change
• Create a PR on GitHub
• Have the change reviewed & merged
Let’s work on a change

• 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
• Deployed to staging
What just happened?

• 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

• Jenkins itself run like a Function-as-a-Service
• One build, in a container, then gone
• Benefits
• Better scalability
• Better isolation
• Jenkins X already uses Jenkins in this manner
• This mode of operation should be available more over time
Serverless Jenkins

• Defend stability through depth, not just tests
GitOps is necessary, but not sufficient for higher velocity

• Feature Flags
• Circuit Breaker
• Canary Deployment
• Better Observability
How do you defend in depth?

• Because there’s nothing like production
• Traffic mirroring
• A/B testing
Leverage Production Traffic

Smarter testing
● 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

Step 1: Dependency Analysis

Step 2: Predictive Test Selection
● 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
37

Deployment Risk Prediction
● 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?
38

What they have done
● 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
39

What they have done
● 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
40

Where This Takes Us

• 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

Software at the speed of ideas
THANK YOU!
www.cloudbees.com

GitOps, Jenkins X &Future of CI/CD

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to GitOps, Jenkins X &Future of CI/CD

Similar to GitOps, Jenkins X &Future of CI/CD (20)

More from Rakuten Group, Inc.

More from Rakuten Group, Inc. (20)

Recently uploaded

Recently uploaded (20)

GitOps, Jenkins X &Future of CI/CD