This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 137
Update release deployment docs #20
Open
marlowpayne
wants to merge
6
commits into
master
Choose a base branch
from
update-release-deployment
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
2c485c9
When merging releases merge master to develop; Cleanup for clarity an…
cc43c29
DRY things up by linking
e6a19ce
Current practices are to not prepend a tag with a 'v'
7a7ae11
Remove git pulls in docs
2f7a8bf
Add point re. updating open dev branches when "master" is updated
be3a3bf
Reference master branch for Release doc example
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -113,36 +113,35 @@ 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`. | ||
You can do this by using the "Merge pull request" button on the release PR. | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. At this point the PR should already be merged and closed (reference earlier steps). |
||
|
||
**TBD: Discuss** | ||
Mike N: Long-lived release branches, yes/no? | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should already be covered by previous steps. |
||
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 <bundle number that was sent to customer>` | ||
* 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 <number>` | ||
* Description: This should also include a link to a confluence JIRA report page that lists all issues in the release. | ||
|
||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After the last two steps have been followed,
master
should be up to date with the release PR's changes. As previously discussed,master
should updatedevelop
so that any hotfixes are caught and included in the downstream update.