Change: fiddle with document structure

1 files changed, 35 insertions, 35 deletions

diff --git a/ci-arch.mdwn b/ci-arch.mdwn
index 21b5dcd..f20a30c 100644
--- a/ci-arch.mdwn
+++ b/ci-arch.mdwn
@@ -404,6 +404,39 @@ items.
 These are some of the important use cases for the CI system, and how
 we plan CI to implement them.
 
+# Architecture
+
+## The WMF development ecosystem
+
+![The WMF development ecosystem, roughly](ecosystem.svg){ height=25% }
+
+The figure above is simplistic, but gives the general idea of what
+happens when a developer is finished with a change:
+
+1. developer pushes a change to Gerrit, which trigger CI
+1. CI builds and tests change (commit stage)
+1. CI deploys to a test environment, runs tests against that
+   (acceptance test stage); if everythins is OK, Gerrit is notified
+   and requests code reviews from relevant parties
+1. testers can request CI it deploy the change to an environment
+   dedicated for manual testing
+1. after a successful code review, CI merges changes to the master
+   branch, runs 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. The two stages may be re-run after code review, to make
+sure nothing unforeseen has changed while the review took place.
+
+Other stages may run in parallel with code review, and if they fail
+they may nullify the release candidacy of the change. 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.
+
 ## Normal change to an individual component
 
 * a developer pushes a change to one program that runs in production
@@ -457,8 +490,6 @@ we plan CI to implement them.
 * this means some builds and builds artifacts need to be locked away
   from public
 
-# Design of specific aspects 
-
 ## Log storage
 
 * We want to capture the build log or "console output" (stdout,
@@ -569,38 +600,7 @@ credentials it needs for accessing the artifacts and doing the
 deployment. There may be several deployment services, for deploying to
 environments with different security needs.
 
-# Architecture: The WMF development ecosystem
-
-![The WMF development ecosystem, roughly](ecosystem.svg){ height=25% }
-
-The figure above is simplistic, but gives the general idea of what
-happens when a developer is finished with a change:
-
-1. developer pushes a change to Gerrit, which trigger CI
-1. CI builds and tests change (commit stage)
-1. CI deploys to a test environment, runs tests against that
-   (acceptance test stage); if everythins is OK, Gerrit is notified
-   and requests code reviews from relevant parties
-1. testers can request CI it deploy the change to an environment
-   dedicated for manual testing
-1. after a successful code review, CI merges changes to the master
-   branch, runs 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. The two stages may be re-run after code review, to make
-sure nothing unforeseen has changed while the review took place.
-
-Other stages may run in parallel with code review, and if they fail
-they may nullify the release candidacy of the change. 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
+# The CI pipeline
 
 ![The default pipeline](pipeline.svg){ height=25% }
 
@@ -709,7 +709,7 @@ Capacity tests, and other tests for non-functional requirements, will
 also be done in dedicated, isolated production-like environments.
 RelEng will work with the performance team to sort out the details.
 
-# Architecture: internals
+# CI implementation
 
 FIXME This needs to be written, but it needs a lot of thinking first