Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

Update release deployment docs #20

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions continuous-deployment.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
32 changes: 16 additions & 16 deletions release-deployment.md
Original file line number Diff line number Diff line change
Expand Up @@ -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`.
Copy link
Author

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 update develop so that any hotfixes are caught and included in the downstream update.


```
$ 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.
Copy link
Author

Choose a reason for hiding this comment

The 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?

Copy link
Author

Choose a reason for hiding this comment

The 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**
Expand Down Expand Up @@ -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.
Expand All @@ -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

Expand All @@ -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:

Expand All @@ -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.

Expand Down