Inspect the Sprint Board. You can use the two filters on top (“InRelease” and “NotInRelease”) to ensure that tickets that are merged on the release branches have the right value on the “Fix Version” field.
Check the tickets status. Talk to people involved to make an informed decision on whether this ticket will make it on time for the release or not.
Update the repository field on release tickets based on the PRs. This will be useful in order to figure out which had changes since the last release and should be tagged on the next steps.
At some point you have to freeze release and inform the Release Notes editor about the final list of tickets. Once this is done start the process below, so developers can keep merging code without affecting the release.
NOTICE: On the Review Column when both “Review Passed” (PR has been merged) and “UAT passed” are clicked, then the ticket is automatically moves to “Done”
Tag applications repositories
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. So first you need to merge that branch to the develop branch. Once this is done you can rebase the languages branch from develop and force push. This will update that branch with any new translatable string.
Now merge the develop branch to master on all repos that have changes since the last release.
Create a new tag on those repos.
NOTICE: All merge actions should take place on local branches that are synced with the remote ones. Example: git checkout languages git pull git checkout develop git pull git merge languages
Bump the base repository
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.
NOTICE: If you include in the subject line of your git commit message the string [AUTO-PROCEED] then, if all tests are successful, it will automatically do all the steps for deploying to production.
Check CI for the planet4-base-fork branch and wait for the workflow to finish, and all the tests to pass.
Merge the develop branch into the release branch.
Merge the release branch into the master branch.
Go back to the base-fork develop workflow in the circleCI (it must appear “on hold”) and approve the job named “hold-trigger-planet4”
The above action will trigger develop workflows on all sites, and then automatically the release workflows. It would take at least 2.5h.
If 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 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: Planet4 reports > Update CircleCI. This will update the CircleCI sheet using CircleCI’s API. You can the open just the ones that are on hold.
NOTICE: If you discover a bug during the Regression Tests report, you can open a ticket.
NOTICE: For GPCH and GPNL, if you see important visual differences please inform the teams. They have access to approve the production pipeline, when they fix any issues. Same applies for websites that are heavily customized (eg. Storytelling). If something is completely broken, hold the release and notify them.
NOTICE: As of today, 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.
During the process, and certainly when it’s completed, inform the Skype group chat about the new release and share a link to the Release Notes.
Doing a release on a single NRO
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 your composer-local.json file of your planet4-mysite 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.
There are some rules though of automatic changes:
If you have any planet4 dependencies on “dev-develop”, then in the promotion to the release branch those will automatically change to the latest release branch of the latest stable tag of the same repo.
In the above example, the child theme was on “dev-develop” in the develop branch, but it got changed to “0.2.10” on the release branch.
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.