diff options
-rw-r--r-- | ci-arch.html | 12 | ||||
-rw-r--r-- | ci-arch.mdwn | 39 | ||||
-rw-r--r-- | ci-arch.pdf | bin | 314960 -> 314927 bytes |
3 files changed, 25 insertions, 26 deletions
diff --git a/ci-arch.html b/ci-arch.html index e175cbb..4a3b77b 100644 --- a/ci-arch.html +++ b/ci-arch.html @@ -52,13 +52,11 @@ <p>It is assumed as of the writing of this document that future CI will build on and deploy to containers orchestrated by Kubernetes.</p> <p>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</p> <h1 id="requirements">Requirements</h1> -<ul> -<li><p>This chapter lists the requirements we have for the CI system and which we design the system to fulfil.</p></li> -<li><p>Each requirement is given a semi-mnemonic unique identifier, so it can be referred to easily.</p></li> -<li><p>The goal is to make requirements be as clear and atomic as possible, so that the implementation can be more easily evaluated against the requirement: it’s better to split a big, complicated requirement into smaller ones so they can be considered separately. The original requirement can be a parent to all its parts.</p></li> -<li><p>FIXME: We may want to have a way to track which requirements are being fulfilled, or tested by automated acceptance tests. Need to add something for this, maybe a spreadsheet.</p></li> -<li><p>These requirements were originally written up in the <a href="https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG/Requirements">WG wiki pages</a> and have been changed a little compared to that (as of the 21 March 2019 version).</p></li> -</ul> +<p>This chapter lists the requirements we have for the CI system and which we design the system to fulfil.</p> +<p>Each requirement is given a semi-mnemonic unique identifier, so it can be referred to easily.</p> +<p>The goal is to make requirements be as clear and atomic as possible, so that the implementation can be more easily evaluated against the requirement: it’s better to split a big, complicated requirement into smaller ones so they can be considered separately. Requirements can be hierarchical: The original requirement can be a parent to all its parts.</p> +<p><strong>FIXME:</strong> We may want to have a way to track which requirements are being fulfilled, or tested by automated acceptance tests. Need to add something for this, maybe a spreadsheet.</p> +<p>These requirements were originally written up in the <a href="https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG/Requirements">WG wiki pages</a> and have been changed a little compared to that (as of the 21 March 2019 version).</p> <h2 id="very-hard-requirements">Very hard requirements</h2> <ul> <li><p>These are non-negotiable requirement that must all be fulfilled by a our future CI system.</p></li> diff --git a/ci-arch.mdwn b/ci-arch.mdwn index 004544e..5c9e6f4 100644 --- a/ci-arch.mdwn +++ b/ci-arch.mdwn @@ -51,25 +51,26 @@ Kubernetes # Requirements -* This chapter lists the requirements we have for the CI system and - which we design the system to fulfil. - -* Each requirement is given a semi-mnemonic unique identifier, so it - can be referred to easily. - -* The goal is to make requirements be as clear and atomic as possible, - so that the implementation can be more easily evaluated against the - requirement: it's better to split a big, complicated requirement - into smaller ones so they can be considered separately. The original - requirement can be a parent to all its parts. - -* FIXME: We may want to have a way to track which requirements are - being fulfilled, or tested by automated acceptance tests. Need to - add something for this, maybe a spreadsheet. - -* These requirements were originally written up in the [WG wiki pages][] - and have been changed a little compared to that (as of the 21 March - 2019 version). +This chapter lists the requirements we have for the CI system and +which we design the system to fulfil. + +Each requirement is given a semi-mnemonic unique identifier, so it can +be referred to easily. + +The goal is to make requirements be as clear and atomic as possible, +so that the implementation can be more easily evaluated against the +requirement: it's better to split a big, complicated requirement into +smaller ones so they can be considered separately. Requirements can be +hierarchical: The original requirement can be a parent to all its +parts. + +**FIXME:** We may want to have a way to track which requirements are +being fulfilled, or tested by automated acceptance tests. Need to add +something for this, maybe a spreadsheet. + +These requirements were originally written up in the [WG wiki pages][] +and have been changed a little compared to that (as of the 21 March +2019 version). [WG wiki pages]: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG/Requirements diff --git a/ci-arch.pdf b/ci-arch.pdf Binary files differindex e1fd8c9..9ac7a26 100644 --- a/ci-arch.pdf +++ b/ci-arch.pdf |