feature/COR-1255-create-workflow-for-acceptance-environment (#4641)

* feature(devops): create workflow for acceptance environment Part of: COR-1255 * feature(devops): add hotfix/* to the trigger branches Part of: COR-1255 * feature(devops): add and update documentation on the CI procedures Part of: COR-1255 --------- Co-authored-by: VWSCoronaDashboard25 <[email protected]>
minvws · Feb 9, 2023 · 104885f · 104885f
1 parent 467bbdd
commit 104885f
Show file tree

Hide file tree

Showing 2 changed files with 50 additions and 5 deletions.
diff --git a/.github/workflows/infra-acceptance.yml b/.github/workflows/infra-acceptance.yml
@@ -0,0 +1,20 @@
+name: CI-acceptance
+on:
+  push:
+    branches:
+      - 'release/*'
+      - 'hotfix/*'
+
+jobs:
+  trigger-acceptance-build:
+    environment: Acceptance
+    name: Call Azure Pipeline
+    runs-on: ubuntu-latest
+    steps:
+      - name: Azure Pipelines Action
+        uses: Azure/[email protected]
+        with:
+          azure-devops-project-url: https://dev.azure.com/${{ secrets.VWS_AZURE_ORGANIZATION_NAME }}/${{ secrets.VWS_AZURE_PROJECT_NAME }}
+          azure-pipeline-name: ${{ secrets.VWS_AZURE_PIPELINE_NAME_ACC }}
+          azure-devops-token: ${{ secrets.VWS_AZURE_DEVOPS_TOKEN }}
+          azure-pipeline-variables: '{"FRONTEND_BRANCH": "${{ github.ref_name }}"}'
diff --git a/docs/ci.md b/docs/ci.md
@@ -19,11 +19,14 @@ when a merge to master occurs.
 
 ## Build pipeline
 
-The pipelines for develop and staging/production are nearly identical.
-The build process is exactly the same, but in the case of a staging build
-the image gets pushed to the staging server, after which the pipeline is
-paused which gives the client the opportunity the check and approve the
-staging deploy and, if approved, can be pushed to production with a push of a button.
+The pipelines for develop and staging/acceptance/production are nearly identical.
+The biggest differences are:
+
+| workflow filename    | triggered by a push to:                  | deploys build on:      | Sanity database | note                                                              |
+|----------------------|------------------------------------------|------------------------|-----------------|-------------------------------------------------------------------|
+| infra-develop.yml    | `origin/develop`                         | development            | development     |                                                                   |
+| infra-acceptance.yml | `origin/release/*`, or `origin/hotfix/*` | acceptance             | production      | The build is always done with the branch that triggers the build. |
+| infra.yml            | `origin/master`                          | staging and production | production      | Deploy to production only happens after approval by the client.   |
 
 The build process follows these steps:
 
@@ -40,4 +43,26 @@ The build process follows these steps:
   - Run lokalize:import to retrieve all the translations from Sanity
   - Run the NextJs build
 
+## Intended Purpose
+Each environment serves a different purpose.
+ - For the `development` environment, the goal is to see if the feature works as intended by the developer.
+   After code is approved by the developers, it is merged to the `develop` branch and the feature is deployed to this environment.
+   Here the feature can be tested for edge cases, utilising the development database in Sanity.
+ - For the `acceptance` environment, the goal is to showcase the features that are intended to be released.
+   When a feature is thoroughly tested, it should be added to this environment.
+   This is done by pushing the feature to a `staging/*` or `hotfix/*` branch.
+ - For the `staging` environment, the goal is to do a final check on all the features that are going to be released.
+   This is done by merging the `staging/*` or `hotfix/*` branch to the `master` branch.
+   After approval by the client, the same build that is deployed on `staging` will be deployed on `production`.
+
+## F.A.Q.
+1. What happens to the acceptance environment after the last `staging` branch is deleted and before the new `staging` branch si created?
+   - The last build will remain on the server, regardless of the existence of the branch that originally triggered that build.
+     This means that nothing happens to the environment, until a new trigger for a new build happens.
+2. What if there are multiple branches that can trigger the acceptance build?
+   - Which ever branch gets pushed to will trigger a build for that branch.
+     That build will be deployed over the previous build.
+     We do have the option to re-trigger a previous action manually.
+     This means we are always in control of which build will be on acceptance.
+
 [Back to index](index.md)