JIRA release preparation

  1. 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.
  2. 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.
  3. At some point you have to freeze release and inform the dev team that nothing else should be merged on the release branches. This means that all new code should either be merged in the develop branch (probably the source branch will need to be rebased for that), or hold merging it until the next release branches are created.
  4. 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.
  5. Send the release tickets to #p4-release on RocketChat, so that Release Notes can be written.

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

  1. 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 release branch.
  2. We follow the Git Flow branching model, so the next steps are:
    • Merge release branch to develop
    • Merge release branch to master
  3. Currently the master branch is the only one that has the minified assets. So after merging the release branch run npm run build to generate the new assets and commit them. Then create a new tag.

Bump the base repository

  1. 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).

    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 production (Without holing at the end of the staging site, aka, it will skip the step 6 bellow)
  2. Check CI for the planet4-base-fork branch and wait for the workflow to finish, and all the tests to pass.
  3. Merge the develop branch into the release branch.
  4. Merge the release branch into the master branch.
  5. Go back to the base-fork develop workflow in the circleCI (it must appear “on hold”) and approve the job named “hold-trigger-planet4”
  1. The above action will trigger develop workflows on all sites, and then automatically the release workflows. It would take at least 2h.
  2. 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”.
  1. 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.
  2. 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.

Creating next release branches

  1. Create the new release branches on all the application repositories that were included in this release.
  2. On master-theme you should bump the version on the style.scss.
  3. On plugins you you should bump the version on the main php file.
  4. After you push these new branches, check open PRs and change the base branch to the new one if needed.
  5. Delete the old release branches.

Doing a release on a single NRO

This is in case you want to do a new release on just one NRO.

  1. 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.
  1. 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.
  2. After the develop has finished building/deploying, your release site will also be build/deployed.

There are some rules though of automatic changes:

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.

  1. Wait for circleCI to build and deploy the release site.
  2. 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!
  1. 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.
  2. Get inside it (click on it), and approve the next step (to trigger the release to your production site):
  1. This should now have triggered the build/deploy of your production site.
  2. A new workflow will appear, with the word “Tag”, this is your production build/deploy workflow.
  3. Wait for the job to finish, and check your production site.
  4. If it fails, then you will have to research to see what went wrong.

Links & Resources