diff options
| author | Lars Wirzenius <lwirzenius@wikimedia.org> | 2019-04-22 13:26:43 -0500 |
|---|---|---|
| committer | Lars Wirzenius <lwirzenius@wikimedia.org> | 2019-04-22 13:26:43 -0500 |
| commit | 8e2515edcf7b8db3f30f9735ff9dea9dfba5e566 (patch) | |
| tree | 136771cf19f1d21dcc9b7874252b9cc2fc096f77 | |
| parent | 5e29d53d1cf83168b7e82e7c12b28c8721aeb2a6 (diff) | |
| download | wmf-talks-8e2515edcf7b8db3f30f9735ff9dea9dfba5e566.tar.gz | |
Add: CI WG phase 2 slides
| -rw-r--r-- | ci-phase2.html | 26 | ||||
| -rw-r--r-- | ci-phase2.mdwn | 155 |
2 files changed, 181 insertions, 0 deletions
diff --git a/ci-phase2.html b/ci-phase2.html new file mode 100644 index 0000000..95756b8 --- /dev/null +++ b/ci-phase2.html @@ -0,0 +1,26 @@ +<!DOCTYPE html> +<html> + <head> + <title>CI WG: Phase 2</title> + <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> + <style type="text/css"> + @import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz); + @import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,700,400italic); + @import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic); + + body { font-family: 'Droid Serif'; } + h1, h2, h3 { + font-family: 'Yanone Kaffeesatz'; + font-weight: normal; + } + .remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; } + </style> + </head> + <body> + <script src="https://remarkjs.com/downloads/remark-latest.min.js" type="text/javascript"> + </script> + <script type="text/javascript"> + var slideshow = remark.create({sourceUrl: 'ci-phase2.mdwn'}); + </script> + </body> +</html> diff --git a/ci-phase2.mdwn b/ci-phase2.mdwn new file mode 100644 index 0000000..46c027d --- /dev/null +++ b/ci-phase2.mdwn @@ -0,0 +1,155 @@ +class: center, middle, inverse + +# CI WG phase 2 + +Let's get real + +--- + +class: center, middle, inverse + +Argo, GitLab CI, Zuul v3—how do we choose? + +--- + +# What do we really, really want? + +* **Faster** cycle times! **Higher** satisfaction! **Stronger** + empowerment! All the good things! + + * Boost productivity and raise developer satisfaction in the + movement + + * Get more bang for the donated buck + +* Self-serve CI—empower developers, spread the work, remove + RelEng from the critical path + +* Speed—what's the minimal cycle time we can achieve? + +* New requirement: Deploy CI via itself! No more manual deployments + for anything ever! + +--- + +# Overall approach + +* Pick at least one of the candidates: Argo, GitLab CI, Zuul v3 (more + if there's time and people) + +* Set up a CI system in parallel with the existing one that does + everything "right", hopefully including deployment to production + +* Use this "for real", with a subset of the projects in CI, in + collaboration with their developers + + * CI itself + * Blubber + * Hopefully other projects, too + +* Gather feedback, make changes, repeat, rinse + +* Gradually switch everything to new CI, keeping old one running until + it's not needed anymore + +--- + +Pipeline design +============================================================================= + +* Does not need to be backwards compatible + +* Code review on Gerrit. Or try GitLab merge requests? + +* Pipeline triggered by developer pushing a change; merges still done + by CI + +* Stages: commit, acceptance test, deployment to production + +--- + +Commit stage +============================================================================= + +* build the program; produce binaries and Docker images and other + artifacts that will eventually be used in all later stages and in + production + +* run unit tests + +* run code health checks + +* commands to build, run unit tests are specified by developer + +* other commands specified by RelEng, can't be overridden by + developer + + * for anything the developers can't be allowed to decide, for the + safety of production + + * e.g., how to build a Docker image + +* if commit stage fails, the pipeline stops + +* commit stage should be fast, less then 300 seconds + + * developers are expected to wait for commit stage to pass after + they push before they move to their next task + +--- + +Acceptance stage +============================================================================= + +* using artifacts from commit stage, deploy a test instance, run + automated acceptance tests against test instance + +* acceptance tests implemented by developers + + * they know what their requirements are + + * they will be responsible for production not breaking so they + need to be able to add any tests they need to be confident + +* additional tests specified by RelEng + + * security checks (port scan for un-acceptable ports?) + + * more? + +* if this stage fails, the pipeline stops + +* this stage may take a while. + +--- + +Further things to consider +============================================================================= + +* Account management? + +* Security support, upgrades, general longevity? + +* Security update embargoes? + +* Transparency into what's happening in CI? + +* Build triggers: scheduled? manual? dependency project built? + +* Rollbacks in development? + +* Traceability from production to the git commit it is built from? + +* Build in K8s or VMs? Does it matter? + +* Artifact storage? + +* Metrics? + +--- + +class: center, middle, inverse + +I have nothing to offer but blood, toil, tears and sweat. + +And fun. Because if CI isn't fun, we're doing it wrong. |