diff options
Diffstat (limited to 'ci-arch.html')
-rw-r--r-- | ci-arch.html | 12 |
1 files changed, 5 insertions, 7 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> |