summaryrefslogtreecommitdiff
path: root/topics/systems
diff options
context:
space:
mode:
authorFrederick Muriuki Muriithi2022-01-13 12:53:12 +0300
committerFrederick Muriuki Muriithi2022-01-13 13:09:40 +0300
commita584c5d9027df929b3bba8df3852ad7a06e759c3 (patch)
treeec99b4fd1fbb5957f545c1090d1bf766e35c62f5 /topics/systems
parent05a554cb3ce9eb0bc4fb22661807ee6b45d81baa (diff)
downloadgn-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/systems')
-rw-r--r--topics/systems/ci-cd.gmi54
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