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. But before that, we need to merge new translations.
The 3 major application repositories (master-theme, plugin-gutenberg-blocks, plugin-gutenberg-engagingnetworks) have a
languages branch. This is where new translations are auto-committed from the Handbook. So first you need to merge that branch to the
master branch. Once this is done you can rebase the languages branch from master and force push it. This will update that branch with any new translatable strings.
git checkout languagesgit pullgit checkout mastergit pullgit merge languagesgit push origin mastergit checkout languagesgit rebase mastergit push -f origin languages
Now on each of the application repositories we can switch to the
master branch, create a new tag and push it.
git tag -a v1.90 -m "v1.90"git push origin v1.90
In the repository planet4-base-fork, in the
develop branch, update the versions of the plugins/themes that you are releasing and the version of composer.json (example). Make sure to also update the Changelog.
Check CI for the planet4-base-fork branch and wait for the workflow to finish, and all the tests to pass.
Now you need to merge the
develop branch to the
release and then the
release branch to the
master branch. You can do this manually if you want, but there is a job on the CI that automates this step. All you have to do is approve the "hold-promote" job.
Go back to the base-fork workflows and wait until the pipelines for master and release complete successfully.
Go back to the base-fork develop workflow in the CI (it must appear “on hold”) and approve the job named “hold-trigger-sites”.
The above action will trigger develop workflows on all sites, and then automatically the release workflows. It would take at least 2.5h.
If you didn’t use the
[AUTO-PROCEED] flag, you have to manually check all the release sites through the CI workflows. If everything looks good, go to the release-hold-and-finish workflow for each one of those (it must appear “on hold”) and approve the job named “hold-promote”.
If you used the
[AUTO-PROCEED] flag, then the sites that passed Visual Regression tests will automatically trigger the production pipeline. You would only have to manually approve (as described on the previous step) only the ones that failed. The easiest way to see which ones failed is to go this spreadsheet and run: Planet 4 > Update CircleCI. This will update the CircleCI sheet using CircleCI’s API. You can the open just the ones that are on hold.
If you haven't done already, update the Changelog. Go back to the base-fork develop pipeline. There is one final approval job about the Changelog. This will send an email notification to the Planet 4 community.
From the steps above it's clear that the order of these 3 steps should be:
The reason for not configuring those in a chained dependency is to leave the option for either skipping one or doing them manually. We may re-visit that at some point.
This is in case you want to do a new release on just one NRO.
Trigger a rebuild/redeploy of the develop site with one of the following two ways:
If a change is needed, do commit and push a change in
composer-local.json file of the relevant planet4-<nro> repository. This will trigger the Develop pipeline of this site.
Go to CircleCI workflows, find the site, and the latest triggered develop pipeline. Rerun it.
Wait for the new pipeline to appear, and wait until it finishes. This will do a new build/deploy of your develop site, and it will trigger a new build and deploy of your release site.
After the develop has finished building/deploying, your release site will also be build/deployed.
Wait for circleCI to build and deploy the release site.
If all has gone well, your release-hold-and-finish workflow should appear to be in “Hold”. This means that it was released successfully on your staging site, and the hold is for your production site!
Confirm that your staging site is ok and has your changes and is on the latest version. Do not run the following step unless you have confirmed the staging site.
Get inside it (click on it), and approve the next step (to trigger the release to your production site).
This should now have triggered the build/deploy of your production site. A new workflow will appear, with the word “Tag”, this is your production build/deploy workflow. Wait for the job to finish, and check your production site. If it fails, then you will have to research to see what went wrong.