From 7776b55b4da532710d1ba1792b87153051ac5417 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Tue, 7 May 2019 16:22:02 +0300 Subject: Change: fiddle with document structure --- ci-arch.mdwn | 70 ++++++++++++++++++++++++++++++------------------------------ 1 file changed, 35 insertions(+), 35 deletions(-) (limited to 'ci-arch.mdwn') 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 -- cgit v1.2.1