Deployment

The Hale Platform can be deployed into four environments, prod, staging, dev and demo. These environments are represented by branches in this repo and by merging your code into these branches you will trigger a build and deployment.

To deploy into each environment we use GitActions. This actions are configured in our cd.yaml file. Here is an example of what the deployment interface looks like:

Deploy to staging or production

Merge or push code to the main branch. This will trigger a deployment to staging. To then deploy to production, you will then have to manually go into the GitActions tab and approve the deployment out to the production environment.

Deploy to dev or demo

Merge or push code to the corresponding branch with the same name. You can check you progress via GitActions workflow chart.

Confirm deployment has been successful

In your terminal run helm list. You should see a timestamp that corresponds to your deployment and status deployed. You can also run kubectl get all. You should see your pods running with a pod status of 2/2 and Running.

Steps to deploy a plugin or Hale theme

1. Make sure plugin or hale theme has changes merged into that repo's main branch.
2. Make sure the version has been updated and new release created.
3. Run CircleCI pp satis which loads the plugin or theme into our Composer repository.
4. Run Composer update in the root of this repo, save and push your changes up to your target branch you wish to deploy to.
5. If pushing to production, you will need to approve manually the deployment from staging to production in GitActions.

Steps to deploy a development branch to Demo without creating a new release

1. Push the development branch in the Hale repo to github.
2. Run CircleCI pp satis which loads the plugin or theme into our Composer repository.
3. Switch to the demo branch of this repo.
4. Edit the composer.json file: Change to "ministryofjustice/wp-hale": "dev-[branch name]", which is on line 38 at time of writing.
5. Ensure you are on the VPN.
6. Run Composer update in the root of this repo, save and push your changes up.
7. To continue work on the development branch, you will need to re-clone the Hale repo and pick up from where you left off.

Deployment Secrets and Variables

The build and deployment git action relies on Github secrets and variables. Most of these are generated by CloudPlatform but some have been manually entered.

Most of secrets/variables for each environment are named the same where possible. Then on deployment it uses GitHub environments to determine which the value to use. This means we can use the same deploy code for all environments making it easier to maintain. Unfortunately due restrictions with the CloudPlatform when the same github repo is being using for multiple namespaces (dev, staging etc..) ecr secrets/variables names are required to have a prefix which has meant that there has to be a workflow job for each environment (we are hoping we can find a way around this in the future).

Secret/Variable Name	Type	Generated/Manual
Content Cell	Content Cell	---------
Content Cell	Content Cell	---------