Change: add some figure, edit text

1 files changed, 36 insertions, 20 deletions

diff --git a/ci-arch.mdwn b/ci-arch.mdwn
index 3bea641..631db06 100644
--- a/ci-arch.mdwn
+++ b/ci-arch.mdwn
@@ -46,6 +46,10 @@ abstract: |
 * It is assumed as of the writing of this document that future CI will
   build on and deploy to containers orchestrated by Kubernetes.
 
+* An important change is that we aim to change things so that as much
+  as possible, all software deployments are to containers
+  orchestrated by Kubernetes
+
 # Requirements
 
 * This chapter lists the requirements we have for the CI system and
@@ -494,9 +498,36 @@ we plan CI to implement them.
 
 FIXME
 
+# Architecture: The WMF development ecosystem
+
+![The WMF development ecosystem, roughly](ecosystem.svg)
+
+* the above figure is simplistic, but gives the general idea
+    * developer pushes a change to Gerrit
+    * CI builds and tests change (commit stage)
+    * CI deploys to a test environment, runs tests against that
+      (acceptance test stage)
+    * CI can deploy to an environment dedicated for manual testing
+    * after successful code review, CI merges changes to the master
+      branch, run all automated tests again, and deploys to the
+      production environment
+
+* the commit and acceptance stages are triggered as soon as developer
+  pushes changes to be reviewed; human reviews won't be requested
+  until the two stages pass, as there's no point in spending human
+  attention on things that are not going to be candidates for
+  deployment to production; they may be re-run after code review
+  accepts the changes, to make sure nothing unforeseen has changed
+  while review took place
+
+* other stages may run in parallel with code review, but if they fail
+  they may nullify candidacy? for example, stages for manual and
+  capacity testing, and security test/review; depending on the change
+  and the component in question, some or all of these may be necessary
+
 # The (default?) pipeline
 
-* FIXME: this could really do with a graph
+![The default pipeline](pipeline.svg)
 
 * CI will provide a default pipeline for all projects
 
@@ -578,27 +609,12 @@ FIXME
   * this can also be used to demonstrate upcoming features that are
     not yet enabled in production
 
-# Architecture: CI in an ecosystem
-
-* code review will be done in Gerrit or otherwise outside the CI
-  pipeline
-
-* the commit and acceptance stages are triggered as soon as developer
-  pushes changes to be reviewed; human reviews won't be requested
-  until the two stages pass, as there's no point in spending human
-  attention on things that are not going to be candidates for
-  deployment to production
-
-* other stages may run in parallel with code review, but if they fail
-  they may nullify candidacy?
-
-* deployments go to K8s, everything will run in containers
-
 # Architecture: internals
 
-FIXME
+FIXME This needs to be written, but it needs a lot of thinking first
 
 # Acceptance criteria
 
-* This chapter sketches some automated acceptance tests using a
-  Gherkin/Cucumber-like pseudo code language.
+* FIXME: This chapter will sketch some automated acceptance tests
+  using a Gherkin/Cucumber-like pseudo code language. Or in some other
+  way that can be automatically executed.