Skip to content
This repository has been archived by the owner on Nov 30, 2021. It is now read-only.

Commit

Permalink
docs(release-checklist.md): update from rc1 amended processes
Browse files Browse the repository at this point in the history
  • Loading branch information
Vaughn Dice committed May 27, 2016
1 parent f76e495 commit 8f524a7
Showing 1 changed file with 88 additions and 43 deletions.
131 changes: 88 additions & 43 deletions src/roadmap/release-checklist.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -21,11 +21,13 @@ A release consists of the following artifacts:
- [fluentd](https://github.com/deis/fluentd)
- [logger](https://github.com/deis/logger)
- [minio](https://github.com/deis/minio)
- [monitor](https://github.com/deis/monitor)
- [postgres](https://github.com/deis/postgres)
- [registry](https://github.com/deis/registry)
- [router](https://github.com/deis/router)
- [slugbuilder](https://github.com/deis/slugbuilder)
- [slugrunner](https://github.com/deis/slugrunner)
- [stdout-metrics](https://github.com/deis/stdout-metrics)
- [workflow](https://github.com/deis/workflow)
- [workflow-e2e](https://github.com/deis/workflow-e2e)
- [workflow-manager](https://github.com/deis/workflow-manager)
Expand All @@ -34,47 +36,92 @@ A release consists of the following artifacts:
images referenced above. For example, if `$WORKFLOW_RELEASE` is `2.0.0-rc1`, the new chart would
be in a new directory called `workflow-rc1`.

# Step 1: Create New Helm Classic Charts
# Step 1: Cut repo branches and push image tags

First, export necessary values for `WORKFLOW_RELEASE` and `WORKFLOW_RELEASE_SHORT`:
```
export WORKFLOW_RELEASE=<full release name>
export WORKFLOW_RELEASE_SHORT=<short form of above>
```
1. Once the release milestone is cleared of tickets in the workflow component repos, the release branches can be cut.

If only a particular repo is ready, navigate to said repo and:
```
git checkout master && git pull upstream master
git checkout -b release-$WORKFLOW_RELEASE && git push upstream release-$WORKFLOW_RELEASE
```
Otherwise, for bulk-cutting all repos at the same time, we will use [sgoings/deis-workflow-group](https://github.com/sgoings/deis-workflow-group) here and in Step 2 below:
```
git clone git@github.com:sgoings/deis-workflow-group.git
cd deis-workflow-group
make git-update # point all repos to latest master commits
BRANCH="release-${WORKFLOW_RELEASE}" NEW="true" make git-checkout-branch
BRANCH="release-${WORKFLOW_RELEASE}" make git-push-branch #(can use DRY_RUN=true)
```

2. tag and push docker images to 'staging' `deisci` org
```
TAG="${WORKFLOW_RELEASE}" ORG="deisci" make docker-tag docker-push #(can use DRY_RUN=true)
```

# Step 2: Create New Helm Classic Charts

Next, we'll create new [Helm Classic](https://github.com/helm/helm-classic) charts so that we can "stage" a
version of our release for testing. Here is the current process to do so:

1. Create a new branch in [deis/charts](https://github.com/deis/charts): `git checkout -b release-$WORKFLOW_RELEASE origin/master`
1. Create a new branch in [deis/charts](https://github.com/deis/charts): `git checkout -b release-$WORKFLOW_RELEASE upstream/master`

2. Download the [deisrel](https://github.com/deis/deisrel) binary via the bintray link provided in the project's README and place it in your `$PATH`
3. Stage copies of all files needing release updates into the appropriate `workflow-$WORKFLOW_RELEASE_SHORT(-e2e)` chart directories. (Note: `deisrel` will automatically fetch the latest commit sha values from the `master` branch of each repo to populate the appropriate component's `dockerTag` in `tpl/generate_params.toml`):

3. Copy the current `dev` charts into new `workflow-$WORKFLOW_RELEASE_SHORT` charts:
```console
cp -r workflow-dev workflow-$WORKFLOW_RELEASE_SHORT
cp -r workflow-dev-e2e workflow-$WORKFLOW_RELEASE_SHORT-e2e
```
deisrel helm-stage --stagingDir workflow-$WORKFLOW_RELEASE_SHORT workflow
deisrel helm-stage --stagingDir workflow-$WORKFLOW_RELEASE_SHORT-e2e e2e

4. Stage copies of all files needing release updates into the appropriate `workflow-$WORKFLOW_RELEASE_SHORT(-e2e)` chart directories:
```console
deisrel helm-stage --tag $WORKFLOW_RELEASE --stagingDir workflow-$WORKFLOW_RELEASE_SHORT workflow
deisrel helm-stage --tag $WORKFLOW_RELEASE --stagingDir workflow-$WORKFLOW_RELEASE_SHORT-e2e e2e
```
4. Delete the `KUBERNETES_POD_TERMINATION_GRACE_PERIOD_SECONDS` env var from `workflow-$WORKFLOW_RELEASE_SHORT/tpl/deis-controller-rc.yaml`
5. Commit your changes:

5. Delete the `KUBERNETES_POD_TERMINATION_GRACE_PERIOD_SECONDS` env var from `workflow-$WORKFLOW_RELEASE_SHORT/tpl/deis-controller-rc.yaml`

6. Test the chart and make sure it installs:
```console
cp -r workflow-$WORKFLOW_RELEASE_SHORT* `helmc home`/workspace/charts
helmc generate workflow-$WORKFLOW_RELEASE_SHORT
helmc install workflow-$WORKFLOW_RELEASE_SHORT
```

Optionally, run the e2e tests as well:
```console
helmc generate workflow-$WORKFLOW_RELEASE_SHORT-e2e
helmc install workflow-$WORKFLOW_RELEASE_SHORT-e2e (to run the e2e tests)
```

7. Commit your changes:
```console
git commit -a -m "chore(workflow-$WORKFLOW_RELEASE_SHORT): releasing workflow-$WORKFLOW_RELEASE_SHORT(-e2e)"
```
6. Push your changes: `git push origin HEAD:release-$WORKFLOW_RELEASE`.
7. Open a pull request from your branch to merge into `master` on https://github.com/deis/charts

# Step 2: Kick off Jenkins Job
8. Push your changes: `git push upstream HEAD:release-$WORKFLOW_RELEASE`.

9. Open a pull request from your branch to merge into `master` on https://github.com/deis/charts

# Step 3: Kick off Jenkins Jobs

Navigate to https://ci.deis.io/job/workflow-test-release/ and kick off a new job with appropriate build parameters filled out, i.e. `HELM_REMOTE_BRANCH=$WORKFLOW_RELEASE` and `RELEASE=$WORKFLOW_RELEASE_SHORT`

As of this writing, the e2e tests in this job are run on a GKE cluster using default (minio) external storage.
As of this writing, the e2e tests in this job are run on a GKE cluster using default (minio) storage. To kick off the supported external storage permutations, run https://ci.deis.io/job/storage_backend_e2e/ w/ `STORAGE_TYPE` of 'gcs' and 'aws', along with the other
values used in job above.

# Step 3: Update Documentation
# Step 4: Update Documentation

Create a new pull request against deis/workflow, updating all references of the old release to
`$WORKFLOW_RELEASE`. Use `git grep $WORKFLOW_OLD_RELEASE` to find any references.
`$WORKFLOW_RELEASE`. Use `git grep $WORKFLOW_OLD_RELEASE` to find any references. (Be careful not to
change `CHANGELOG.md`)

Also, note there may be an occurrence of the previous oldest release (prior to `$WORKFLOW_OLD_RELEASE`) in
`upgrading-workflow.md`. This should be changed to `$WORKFLOW_OLD_RELEASE`.

# Step 4: Manual Testing
# Step 5: Manual Testing

After the chart is created with the immutable Docker image tags that represent the final images
(i.e. the ones that will be re-tagged to the immutable release tag, such as `2.0.0-rc1`), it
Expand All @@ -93,48 +140,46 @@ Amazon S3 |


!!! note

If bugs are found and fixes are made, do the following:

- Update the appropriate docker tag(s) in the `generate_params.toml` file
- Push this change to the release branch
- PR the fix, get it reviewed and merged into master of component repo(s)
- git cherry-pick <issue_fix_sha> into the `release-$WORKFLOW_RELEASE` branch(es) of component repo(s)
- retag the `git-<issue_fix_sha>` image with `$WORKFLOW_RELEASE` and push to 'staging' `deisci` quay org.

# Step 5: Tag and Push Docker Images
# Step 6: Tag and Push Docker Images

After everyone has tested and determined that there are no show-stopping problems for this release,
it's time to tag each individual Docker image with `$WORKFLOW_RELEASE`.

To do so, simply go back to the directory where you checked out the `deis-workflow-group` repo
and run the following two commands to tag and push updated docker images:
and run the following two commands to tag and push updated docker images to the 'prod' `deis` quay org:

```console
make git-update
TAG=$WORKFLOW_RELEASE make docker-tag docker-push
BRANCH="release-$WORKFLOW_RELEASE" make git-checkout-branch
TAG=$WORKFLOW_RELEASE ORG="deis" make docker-tag docker-push
```

# Step 6: Update Helm Classic Chart
# Step 7: Update Helm Classic Chart

Now that new Docker images are on public Docker repositories, it's time to update the Helm Classic chart
to reference the official images. We will use `deisrel` to do this. The following will change every `dockerTag` value
to the same `$WORKFLOW_RELEASE` as well as now pointing to the `deis` quay org.

```
deisrel helm-params --stage --tag $WORKFLOW_RELEASE --org deis workflow
deisrel helm-params --stage --tag $WORKFLOW_RELEASE --org deis e2e
```

Copy the updated files back into charts:
```
cp -r staging/workflow-dev/* workflow-$WORKFLOW_RELEASE_SHORT
cp -r staging/workflow-dev-e2e/* workflow-$WORKFLOW_RELEASE_SHORT-e2e
```console
cd <back_to_charts_dir>
deisrel helm-stage --tag $WORKFLOW_RELEASE --stagingDir workflow-$WORKFLOW_RELEASE_SHORT --org deis workflow
deisrel helm-stage --tag $WORKFLOW_RELEASE --stagingDir workflow-$WORKFLOW_RELEASE_SHORT-e2e --org deis e2e
```

Double-check that `workflow-dev/tpl/generate_params.toml`, has the value `https://versions.deis.com` for `versionsApiURL` entry under `workflowManager`.

When you're done, commit and push your changes. You should get your pull request reviewed and merged before continuing.

**Note:** If non-release-specific amendments have been made to the release chart that do not exist in the `workflow-dev`, be sure to PR said changes for this chart as well.
!!! note

If non-release-specific amendments have been made to the release chart that do
not exist in the `workflow-dev`, be sure to PR said changes for this chart as well.

# Step 7: Update Changelogs
# Step 8: Update Changelogs

At this point, part of the first part and all of the second part of the release is complete.
That is, the Helm Classic chart for the new Workflow version is done, and new Docker versions for all
Expand Down Expand Up @@ -166,23 +211,23 @@ git push -u $YOUR_FORK_REMOTE release-$WORKFLOW_RELEASE_SHORT

Before you continue, ensure pull requests in all applicable repositories are reviewed, and merge them.

# Step 8: Tag and Push Git Repositories
# Step 9: Tag and Push Git Repositories

The final step of the release process is to tag each git repository, and push the tag to each
GitHub project. To do so, simply run the below command in the `deisrel` repository:

```console
deisrel git tag $WORKFLOW_RELEASE
deisrel git tag --ref release-$WORKFLOW_RELEASE $WORKFLOW_RELEASE
```

# Step 9: Close GitHub Milestones
# Step 10: Close GitHub Milestones

Close the github milestone by creating a new pull request at
[seed-repo](https://github.com/deis/seed-repo). Any changes merged to master on that repository
will be applied to all of the component projects. If there are open issues attached to the
milestone, move them to the next upcoming milestone before merging the pull request.

# Step 10: Let Everyone Know
# Step 11: Let Everyone Know

Jump in #company on slack and let folks know that the release has been cut! This will let
folks in supporting functions know that they should start the release support process including
Expand Down

0 comments on commit 8f524a7

Please sign in to comment.