Our main orchestration repository for triggering deployment pipelines is planet4-base-fork. But before we make any change there we need first to prepare the application repositories.
The only change that it's actually needed is to tag the repositories that have new code since the previous release.
On each one of the above repositories that need to be tagged switch to the
master branch and create a new tag.
git tag -a vX.XX -m "vX.XX"git push --tags
planet4-base-fork repository has two main branches:
develop: Controls the develop pipeline and what is being deployed on develop sites.
master: Controls the release pipeline and what is being deployed first on stagning and then on production sites.
So every time there is a new Planet 4 version to be released there it's not required to also update the develop sites, but it's a good practice to first update the
develop branch (so it's not left behind) and then merge it to
All you have to do is edit
composer.json, update the versions of the plugins/themes as needed and the version of composer itself (example).
If you updated the
develop branch, its pipeline will be "on hold". You do not need to trigger that now, because it would delay the production release. You can approve it later.
Check CI for the
release pipeline. When all tests pass it will stay "On Hold" waiting for a manual approval.
Approve that and it will trigger the release pipeline on all websites. This is an overview of a release pipeline for a website:
There is a "hold-promote" job there that controls whether the pipeline will continue deploying on production. This job will be approved automatically (from the "promote" job) if all tests pass successfully.
You will only need to manuall approve that in two cases:
You added a
[HOLD] on your commit message on base-fork. This will require manual approval on all websites.
Visual Regression tests failed on a specific website. You can use this spreadsheet and run: Planet 4 > Update CircleCI. This will update the CircleCI sheet using CircleCI’s API. You can then open just the ones that are on hold.
You can then check the tests report to confirm that the visual differences are acceptable.
If you spot important visual differences on websites with customized child themes you should inform them and don't approve the deployment to production. They have CI access to approve it when ready. This includes: GPCH, GPNL, GPLX and all GPNORDIC websites.
Currently, we don’t do releases on these 3 websites: Korea, Hongkong, Taiwan. These won’t be triggered anyway, so you don’t have to check them.