diff options
author | Frederick Muriuki Muriithi | 2022-01-13 12:53:12 +0300 |
---|---|---|
committer | Frederick Muriuki Muriithi | 2022-01-13 13:09:40 +0300 |
commit | a584c5d9027df929b3bba8df3852ad7a06e759c3 (patch) | |
tree | ec99b4fd1fbb5957f545c1090d1bf766e35c62f5 /topics | |
parent | 05a554cb3ce9eb0bc4fb22661807ee6b45d81baa (diff) | |
download | gn-gemtext-a584c5d9027df929b3bba8df3852ad7a06e759c3.tar.gz |
Add some possible steps for automated CI/CD
Add an outline for the possible steps for implementing the automated
continuous integration/continuous deployment system.
These are a starting point, and will probably evolve over time to be
more robust and be better documented.
Diffstat (limited to 'topics')
-rw-r--r-- | topics/systems/ci-cd.gmi | 54 |
1 files changed, 53 insertions, 1 deletions
diff --git a/topics/systems/ci-cd.gmi b/topics/systems/ci-cd.gmi index e170292..4614427 100644 --- a/topics/systems/ci-cd.gmi +++ b/topics/systems/ci-cd.gmi @@ -46,4 +46,56 @@ testing and deployment, maybe once an hour or so. Once the next battery of tests is passed, the CI/CD system will create a build/artifact to be deployed to staging and have the next battery of tests runs against it. If that passes, then that artifact could be -deployed to production, and details on the commit and
\ No newline at end of file +deployed to production, and details on the commit and + +#### Possible Steps + +Below are some possible steps (and tasks) to undertake for automated deployment + +##### STEP 01: Build package + +- Triggered by a commit to "main" branch (for now) +- Trigger build of the package +- Run unit tests as part of the build: maybe the testing phase should be added to the genenetwork3 definition +- If the build fails (tests fail, other failures): abort and send notifications to development team +- If build succeeds, go to STEP 02 + +##### STEP 02: Deploy to Staging + +- Triggered by a successful build +- Run in intervals of maybe one hour or so... +- Build the container/VM for deployment: here's the first time `guix system container ...` is run +- Deploy the container/VM to staging: the details are fuzzy here +- Run configuration tests here +- Run performance tests +- Run integration tests +- Run UI tests +- Run ... tests +- On failure, abort and send out notification to development team +- On success go to STEP 03 + +##### STEP 03: Deploy to Release Candidate + +- Triggered by a successful deploy to Staging +- Run in intervals of maybe 6 hours +- Pick latest successful commit to pass staging tests +- Build the container/VM for deployment: run `guix system container ...` or reuse container from staging +- Update configurations for production +- Run configuration tests +- Run acceptance tests +- On failure, abort and send out notification to development team +- On success go to STEP 04 + +##### STEP 03: Deploy to Production + +- Triggered by a successful Release Candidate +- Tag the commit as a release + - Maybe include the commit hash and date + e.g gn3-v0.0.12-794db6e2-20220113 +- Build the container/VM for deployment + - run `guix system container ...` or reuse container from staging + - tag container as a release container +- Deploy container to production +- Generate documentation for tagged commit +- Generate guix declaration for re-generating the release +- Archive container image, documentation and guix declaration for possible rollback |