diff options
| author | Lars Wirzenius <lwirzenius@wikimedia.org> | 2019-05-13 17:08:45 +0300 |
|---|---|---|
| committer | Lars Wirzenius <lwirzenius@wikimedia.org> | 2019-05-13 17:08:45 +0300 |
| commit | 08d33c97433ca4f758ecdd045db8bb1dac925387 (patch) | |
| tree | 05b54aca334a12ae46501d342b23c842bc25d387 | |
| parent | dc92510b69eafde75dcdc8bb14b9f1ef28591992 (diff) | |
| download | wmf-ci-arch-08d33c97433ca4f758ecdd045db8bb1dac925387.tar.gz | |
Add: note that wip changes can be reviewed before CI
| -rw-r--r-- | ci-arch.html | 2 | ||||
| -rw-r--r-- | ci-arch.mdwn | 12 | ||||
| -rw-r--r-- | ci-arch.pdf | bin | 284528 -> 284609 bytes |
3 files changed, 8 insertions, 6 deletions
diff --git a/ci-arch.html b/ci-arch.html index 76ab672..90b7049 100644 --- a/ci-arch.html +++ b/ci-arch.html @@ -200,7 +200,7 @@ <li>testers can request CI it deploy the change to an environment dedicated for manual testing</li> <li>after a successful code review, CI merges changes to the master branch, runs all automated tests again, and deploys to the production environment</li> </ol> -<p>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.</p> +<p>The commit and acceptance stages are triggered as soon as developer pushes changes to be reviewed. Human reviews won’t be requested automatically 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. Developer may request reviews of work-in-progress changes when they want. The two stages may be re-run after code review, to make sure nothing unforeseen has changed while the review took place.</p> <p>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.</p> <h2 id="normal-change-to-an-individual-component">Normal change to an individual component</h2> <ul> diff --git a/ci-arch.mdwn b/ci-arch.mdwn index cd052f2..3b365c5 100644 --- a/ci-arch.mdwn +++ b/ci-arch.mdwn @@ -424,11 +424,13 @@ happens when a developer is finished with a change: 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. +pushes changes to be reviewed. Human reviews won't be requested +automatically 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. Developer may request reviews of +work-in-progress changes when they want. 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, diff --git a/ci-arch.pdf b/ci-arch.pdf Binary files differindex f79759f..038cf80 100644 --- a/ci-arch.pdf +++ b/ci-arch.pdf |