From 9ae4671b9c9d76e9c226a2e052089d9af8b31f5a Mon Sep 17 00:00:00 2001 From: Rafael Solorzano <61289255+rafasdc@users.noreply.github.com> Date: Mon, 29 Apr 2024 14:09:07 -0700 Subject: [PATCH 1/2] docs: add feature deployment docs --- docs/deployment.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 docs/deployment.md diff --git a/docs/deployment.md b/docs/deployment.md new file mode 100644 index 0000000000..544bea6cbd --- /dev/null +++ b/docs/deployment.md @@ -0,0 +1,46 @@ +# Feature Deployment Process Documentation + +## Overview + +This document outlines the Continuous Integration and Continuous Deployment (CI/CD) process for managing feature environments, code review, approval, and release processes. + +## Development Process/PR Process + +1. **PR Creation and Drafting:** + - When a Pull Request (PR) is created, it starts as a draft. +2. **Ready for Review:** + - Once the PR is toggled to "ready for review", the following will happen: + - a. A new database is created with the branch name as the database name, and the test database is copied over to the new database. Database creation is handled by the PG operator, and the copy operation is performed by an Openshift job using psql with the test namespace as the source. + - b. The application is deployed with the new feature using Helm, using the branch name as the Helm release name (truncated to 40 characters.) + - c. With each subsequent change, the database is reset, and the Helm release is updated to the new version. +3. **PR Closure:** + - If the PR is toggled back to draft or gets merged: + - a. The feature database is dropped and removed, and the Helm release is uninstalled. + +## Approval Process + +1. **Developer Approval:** + - One developer approval is required before merge can occur. +2. **Notification to PO:** + - Once a developer approves a PR, the Product Owner (PO) is notified: + - a. A comment is created on the related JIRA ticket with the feature environment. + - b. The issue is transitioned to "PO Review" status, triggering JIRA Automation that emails the PO with a direct link to the issue. +3. **PO Approval:** + - If the PO approves, the developer is notified to start the merge/release process. Otherwise, the PR needs to be marked as draft by the developer. + +## Code Merge/Release Process + +1. **Tag and Release Creation:** + - After PO approval, a tag and release are automatically created by GitHub Actions upon checking the box "Check me to trigger release process." on the PR description. Alternatively, it can be performed by running `make release`. +2. **Checks:** + - Multiple checks are performed as part of the above step, including checks for duplicate tags, approvals, and ensuring the PR is up to date with the main branch. +3. **Merge and Deployment:** + - If all checks pass, the PR can be safely merged, and it will automatically be deployed to the test and then production environments. + +## Diagram + +For a detailed diagram of the process please refer to the live miro diagram [here](https://miro.com/app/board/uXjVNkUAjsA=/). + +## Conclusion + +This CI/CD process streamlines development, code review, approval, and release processes, ensuring efficient and reliable feature deployment while maintaining quality and consistency. From 39013fa272d41ba5d7646c31337d1c0e8591d44f Mon Sep 17 00:00:00 2001 From: Rafael Solorzano <61289255+rafasdc@users.noreply.github.com> Date: Tue, 7 May 2024 13:06:53 -0700 Subject: [PATCH 2/2] docs: add exceptions info for merge and release --- docs/deployment.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/deployment.md b/docs/deployment.md index 544bea6cbd..25d3fcad35 100644 --- a/docs/deployment.md +++ b/docs/deployment.md @@ -37,6 +37,13 @@ This document outlines the Continuous Integration and Continuous Deployment (CI/ 3. **Merge and Deployment:** - If all checks pass, the PR can be safely merged, and it will automatically be deployed to the test and then production environments. +### Exceptions + +Note: Release-it process does not allow creation of new tags (it won't delete and recreate automatically) if they already exist. The two scenarios below might occur: + +- If a release is being run on a stale PR, it will fail as it will attempt to release an already existing version (as it has been merged into main) +- If a release is being run at the same time as another one, they might conflict until one is merged in and the other updated (unlikely to happen, but will need communication between developers if this is occurring) + ## Diagram For a detailed diagram of the process please refer to the live miro diagram [here](https://miro.com/app/board/uXjVNkUAjsA=/).