From 1e4268f293470b8d2dec339ce34ede37a10331be Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Mon, 20 May 2019 19:13:36 +0300 Subject: Change: show separate deployment stage for pipeline, drop artifacts --- ci-arch.html | 7 +++-- ci-arch.pdf | Bin 285787 -> 286488 bytes pipeline.dot | 10 +++---- pipeline.svg | 89 +++++++++++++++++++++++++---------------------------------- 4 files changed, 46 insertions(+), 60 deletions(-) diff --git a/ci-arch.html b/ci-arch.html index 71c3195..2153b3c 100644 --- a/ci-arch.html +++ b/ci-arch.html @@ -90,11 +90,12 @@

This is partly due to the SELFHOSTABLE requirement, but also because a WMF value is to prefer open source.

  • GITSUPPORT Must support git. We’re not switching version control systems for CI.

    • -

  • UNDERSTANDABLE Must be understandable without too much effort to our developers so that they can use CI/CD productively. Acceptance critera: our developers can use CI productively, after given a short, 1-page tutorial on how to specify build instructions for their software. FIXME: This might not be very clear.

    • +

  • UNDERSTANDABLE Must be understandable without too much effort to our developers so that they can use CI/CD productively. Acceptance critera: our developers can use CI productively, after given a short, 1-page tutorial on how to specify build instructions for their software. FIXME: This might not be very clear; suggetions welcome.

  • SELFSERVE Must support self-serve CI, meaning we don’t block people if they want CI for a new repo. Due to PROTECTPRODUCTION, there will probably to be some human approval requirement for new projects, but as much as possible, people should be allowed to do their work without having to ask permission.

    • +

  • POSTMERGETESTS All automated tests must pass both before and after merging a change. This can be achieved by various means (run tests twice, or make sure target branch doesn’t change in between). The justification is that the way Gerrit and Zuul currently work, the target branch may change while other changes are reviewed and tested, so we run some test after a merge (but possibly before publishing the merge?). FIXME: is this adequate?

    • Hard requirements

    These are not absolute requirements, and can be negotiated, but only to a minor degree.

    @@ -132,7 +133,6 @@

  • CONFIGVC Must keep configuration in version control. This is needed so that we can track changes over time.

  • GATING Must support gating / pre-merge testing. FIXME: This needs to be explained.

  • PERIODICBUILDS Must support periodic / scheduled testing. This is needed so that we can test that changes to the environment haven’t broken anything. An example would be changes to Debian, upon which we base our container images.

    • -

  • POSTMERGETESTS Must support post-merge testing. FIXME: This needs to be explained.

  • CIMERGES Must support tooling to do the merging, instead of developers. We don’t want developer merging by hand and pushing the merges. CI should test changes and merge only if tests pass, so that the branches for main lines of development are always releaseble.

  • TESTVC Must support storing tests in version control. This is probably best achieved by having tests be stored in the same git repository where the code is.

  • BUILDDEPS Must have some way to declare dependent repositories / software needed for testing. FIXME: This needs to be explained.

    • @@ -150,7 +150,8 @@

  • SLA: RelEng provides a promise, similar to a service-level agreement, for how well CI serves WMF and the movement.

  • HA Must be highly available - can restart any component without disrupting service.

    • -

  • CLEANWORKSPACE Must provide a clean workspace for each build or test run - either a clean VM or container.

    • +

  • CLEANBUILDENV Must provide a build environment with only explicitly declared build dependencies installed.

    • +

  • CLEANWORKSPACE Must provide a clean workspace for each build or test run - either a clean VM or container. The workspace should have the source code of the project to be built, with the right commit checked out from version control, and anything else explicitly declared, but nothing else.

  • SECRETS Must support secure storage of credentials / secrets.

    • Softer requirements

    diff --git a/ci-arch.pdf b/ci-arch.pdf index 09edfad..f3a6de8 100644 Binary files a/ci-arch.pdf and b/ci-arch.pdf differ diff --git a/pipeline.dot b/pipeline.dot index 0c56148..dd31fa0 100644 --- a/pipeline.dot +++ b/pipeline.dot @@ -2,17 +2,15 @@ digraph pipeline { developer [shape="circle" label="developer"]; commit [shape="rect" label="Commit stage"]; acceptance [shape="rect" label="Acceptance stage"]; - artifacts [shape="cylinder" label="Artifact store"]; testenv [shape="folder" label="A test environment"]; + deployprod [shape="rect" label="Deploy to production"]; production [shape="folder" label="Production environment"]; developer -> commit; - commit -> artifacts; commit -> acceptance; - acceptance -> testenv; - artifacts -> testenv; + acceptance -> testenv [style=dotted]; - acceptance -> production; - artifacts -> production; + acceptance -> deployprod; + deployprod -> production; } diff --git a/pipeline.svg b/pipeline.svg index 7992246..97a3d75 100644 --- a/pipeline.svg +++ b/pipeline.svg @@ -4,89 +4,76 @@ - - + + pipeline - + developer - -developer + +developer commit - -Commit stage + +Commit stage developer->commit - - + + acceptance - -Acceptance stage + +Acceptance stage - + commit->acceptance - - + + - + -artifacts - - -Artifact store +testenv + +A test environment - - -commit->artifacts - - + + +acceptance->testenv + + - + -testenv - -A test environment +deployprod + +Deploy to production - + -acceptance->testenv - - +acceptance->deployprod + + production - -Production environment - - - -acceptance->production - - + +Production environment - + -artifacts->testenv - - - - - -artifacts->production - - +deployprod->production + + -- cgit v1.2.1