diff --git a/continuous-deployment.md b/continuous-deployment.md index 403cccc..785648c 100644 --- a/continuous-deployment.md +++ b/continuous-deployment.md @@ -121,3 +121,5 @@ described above.* 1. When the pull request has been reviewed and ![+1'd](images/plus1.png) , merge and close it and then delete the `hotfix-documentation-broken-links` branch. This can all be done from the Github pull-request page. + +1. Merge `master` into any open `hotfix-` branches. diff --git a/release-deployment.md b/release-deployment.md index 22f2c49..02b29f3 100644 --- a/release-deployment.md +++ b/release-deployment.md @@ -113,7 +113,7 @@ There's nothing special about that. Each developer follows the above [Develop a * Base: `master` * Compare: `release-vX.Y.Z` Paste the Release Checklist into the PR body. Each project should define a release - checklist. It will vary across projects, but you can refer to the Astro [Release](https://github.com/mobify/astro/blob/develop/RELEASE.md) document + checklist. It will vary across projects, but you can refer to the Mobify Code Style [Release](https://github.com/mobify/mobify-code-style/blob/master/RELEASE.md) document for an example. 1. At some point in the checklist you will merge the release branch into `master`. @@ -121,28 +121,27 @@ There's nothing special about that. Each developer follows the above [Develop a 1. Now you are ready to create the actual release. Navigate to the project page on Github and draft a new release with the following settings: - * Tag version: `vX.Y.Z` + * Tag version: `X.Y.Z` * Target: `master` * Release title: `Release vX.Y.Z` * Description: Include a high-level list of things changed in this release. Click `Publish release`. -1. Merge the `release-vX.Y.Z` into `develop`. +1. Merge `master` into `develop`. ``` $ git checkout develop - $ git merge release-vX.Y.Z + $ git merge master $ git push ``` -1. Finish off the tasks in the release checklist. Once everything is done, close - the release PR. +1. Merge `master` into any open `release-vX.Y.Z` or `hotfix-` branches. + +1. Finish off the tasks in the release checklist. **TBD: Discuss** Mike N: Long-lived release branches, yes/no? -1. Create the release on Github from `master`. - ### Change in plan, pull a feature from a release **TBD: Discuss** @@ -192,7 +191,7 @@ code in it already. 1. Now that the hotfix code is in `master` you are ready to create the actual release. Navigate to the project page on Github and draft a new release with the following settings: - * Tag version: `vX.Y.Z` + * Tag version: `X.Y.Z` * Target: `master` * Release title: `Release vX.Y.Z (hotfix)` * Description: Include a high-level list of things changed in this release. @@ -203,16 +202,17 @@ code in it already. patch part of the version when releasing a hotfix and so even hotfixes go through the process of creating a release like this.* -1. Merge the `hotfix-documentation-broken-links` into `develop`. +1. Merge `master` into `develop`. ``` $ git checkout develop - $ git merge hotfix-documentation-broken-links + $ git merge master $ git push ``` -1. Finish off the tasks in the release checklist. Once everything is done, close - the hotfix PR. +1. Merge `master` into any open `release-vX.Y.Z` or `hotfix-` branches. + +1. Finish off the tasks in the release checklist. ## Migrate a legacy project @@ -233,13 +233,13 @@ The process for tagging and merging is a bit different when deploying a bundle, 1. Create a bundle to be sent to the customer for verification and approval off of the `release-vX.Y.Z` branch. - Ensure you have installed the automated bundle message script found [here] (https:// mobify.atlassian.net/wiki/questions/81789082/how-do-i-automate-a-bundle-message-using-bash). Follow these steps: + Ensure you have installed the automated bundle message script found [here] (https://mobify.atlassian.net/wiki/questions/81789082/how-do-i-automate-a-bundle-message-using-bash). Follow these steps: ``` $ grunt push -m "$(message Mobile X.Y.Z)" ``` -1. When creating a pull request to merge the release branch into `master` ensure that the standard workflow for _creating a release_ is followed with these specific changes: +1. When creating a pull request to merge the release branch into `master` ensure that the [standard workflow for _creating a release_](#create-and-deploy-a-release) is followed with these specific changes: * Name/Summary: `DEPLOYMENT MERGE: release-v.X.Y.Z, bundle ` * Description: @@ -262,7 +262,7 @@ The process for tagging and merging is a bit different when deploying a bundle, 1. Once the customer has approved the bundle. The bundle is published to production and post launch tests occur. Once all tests have passed, the pull request is merged into `master`. -1. Finish the _Github release workflow_ as described above and ensure that these specific changes are added to the _release notes_ draft of the _Github release_: +1. Finish the _Github release workflow_ as described [here](#create-and-deploy-a-release) and ensure that these specific changes are added to the _release notes_ draft of the _Github release_: * Release title: `Release vX.Y.Z - Bundle ` * Description: This should also include a link to a confluence JIRA report page that lists all issues in the release.