From 104885f503dc613543736e0d4433af8f9d0588c5 Mon Sep 17 00:00:00 2001 From: VWSCoronaDashboard25 <98813868+VWSCoronaDashboard25@users.noreply.github.com> Date: Thu, 9 Feb 2023 15:47:33 +0100 Subject: [PATCH] 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 --- .github/workflows/infra-acceptance.yml | 20 +++++++++++++++ docs/ci.md | 35 ++++++++++++++++++++++---- 2 files changed, 50 insertions(+), 5 deletions(-) create mode 100644 .github/workflows/infra-acceptance.yml diff --git a/.github/workflows/infra-acceptance.yml b/.github/workflows/infra-acceptance.yml new file mode 100644 index 0000000000..e7f5b27ab4 --- /dev/null +++ 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/pipelines@v1.2 + 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 index 0ff75c1d24..be16359f7f 100644 --- 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)