3.9 Release (2019-10-20)

tsenart commented 5 years ago

At the start of the month (2019-10-01)

[x] Choose dates/times for the steps in this release process and update this issue template accordingly. Note that this template references working days, which do not include weekends or holidays observed by Sourcegraph.
[x] Add events to the shared Release Schedule calendar in Google and invite team@sourcegraph.com.
- [x] Creating the release branch.
- [x] Tagging the final release.
- [x] Publishing the blog post.
[x] Send message to #dev-announce with a link to this tracking issue to notify the team of the release schedule.
[x] Create the retrospective document and schedule the retrospective meeting within a few days after the release (send calendar invites to team@sourcegraph.com).
[x] Create a new test grid for 3.9 by cloning the previous release testing grid on Airtable and renaming it to "3.9 Release test grid".
- [x] Reset all tested cells to "To test", unless the "Automated" column is marked as "Done".
- [x] Assign rows in the release testing grid to engineers from the team that owns the row.
[x] Create reminders for yourself to preform the remaining sections in this checklist at appropriate times.

5 working days before release (2019-10-14)

[x] Private message each teammate who has open issues in the milestone and ask them to remove any issues that won't be done by the time that the release branch is scheduled to be created.
[x] Verify that there is a draft of the blog post and that it will be ready to be merged on time.
[x] Ping each team, and ask them to identify which of the optional rows that they own on the release testing grid should be tested this iteration.
[x] Ping the @distribution team to determine which environments each row on the release testing grid should be tested in.

4 working days before release (2019-10-15)

[x] HH:MM AM/PM PT Add a new section header for this version to the CHANGELOG immediately under the ## Unreleased changes heading and add new empty sections under ## Unreleased changes (example).
[x] Create the 3.9 branch for this release off of the changelog commit that you created in the previous step.

[x] Tag the first release candidate v3.9.0-rc.1:

VERSION='v3.9.0-rc.1' bash -c 'git tag -a "$VERSION" -m "$VERSION" && git push origin "$VERSION"'

[x] Send a message to #dev-announce to announce the release candidate.
[x] Run Sourcegraph Docker image with no previous data.
- [x] Run the new version of Sourcegraph.
```
CLEAN=true IMAGE=sourcegraph/server:3.9.0-rc.1 ./dev/run-server-image.sh
```
- [x] Initialize the site by creating an admin account.
- [x] Add a public repository (i.e. https://github.com/sourcegraph/sourcegraph).
- [x] Add a private repository (i.e. https://github.com/sourcegraph/infrastructure).
- [x] Verify that code search returns results as you expect (depending on the repositories that you added).
- [x] Verify that basic code intelligence works on Go or TypeScript.
[x] Upgrade Sourcegraph Docker image from previous released version.
- [x] Run the previous version of Sourcegraph.
```
CLEAN=true IMAGE=sourcegraph/server:$OLDVERSION ./dev/run-server-image.sh
```
- [x] Initialize the site by creating an admin account.
- [x] Add a public repository (i.e. https://github.com/sourcegraph/sourcegraph).
- [x] Add a private repository (i.e. https://github.com/sourcegraph/infrastructure).
- [x] Stop the previous version of Sourcegraph and run the new version of Sourcegraph with the same data.
```
CLEAN=false IMAGE=sourcegraph/server:3.9.0-rc.1 ./dev/run-server-image.sh
```
- [x] Verify that code search returns results as you expect (depending on the repositories that you added).
- [x] Verify that basic code intelligence works on Go or TypeScript.
[ ] Run the new version of Sourcegraph on a clean Kubernetes cluster with no previous data.
- [ ] Create a new Kubernetes cluster using https://github.com/sourcegraph/deploy-k8s-helper.
- [ ] Add a public repository (i.e. https://github.com/sourcegraph/sourcegraph).
- [ ] Add a private repository (i.e. https://github.com/sourcegraph/infrastructure).
- [ ] Verify that code search returns results as you expect (depending on the repositories that you added).
- [ ] Verify that basic code intelligence works on Go or TypeScript.
- [ ] Tear down this Kubernetes cluster.
[x] Delete entries from section 15 (CHANGELOG) of the testing grid, or move them into permanent sections above. Add new CHANGELOG items for this release into section 15. Assign the feature owner as the tester for each row.
[x] Send a message to #dev-announce to kick off testing day.
- [x] Include a link to the testing grid.
- [x] Include the command to run the latest release candidate:
```
IMAGE=sourcegraph/server:3.9.0-rc.1 ./dev/run-server-image.sh
```
- [x] Mention that testing is the top priority, it is expected to take the whole day, and that known or suspected regressions should be tagged as release blockers. Mention that, for other issues found, high-level details like customer impact should be added to help Product determine whether it's a release blocker.

3 working days before release (2019-10-16)

[x] Send a message to #dev-announce to report whether any release blocking issues were found.
[x] Add any release blocking issues as checklist items here and start working to resolve them.
[x] Review all open issues in the release milestone that aren't blocking and ask assignees to triage them to a different milestone (backlog preferred).

As necessary

git cherry-pick bugfix (not feature!) commits from master into the release branch.
Aggressively revert features that may cause delays.
Re-test any flows that might have been impacted by commits that have been cherry picked into the release branch.
Tag additional release candidates.

1 working day before release (2019-10-18)

[x] HH:MM AM/PM PT Tag the final release.

VERSION='v3.9.0' bash -c 'git tag -a "$VERSION" -m "$VERSION" && git push origin "$VERSION"'

[x] Send a message to #dev-announce to announce the final release.
[x] Verify that all changes that have been cherry picked onto the release branch have been moved to the appropriate section of the CHANGELOG on master.
[x] Wait for the final Docker images to be available at https://hub.docker.com/r/sourcegraph/server/tags.
[x] In deploy-sourcegraph:
- [x] Wait for Renovate to open a PR to update the image tags and merge that PR (example).
- [x] Create the 3.9 release branch from this commit.
- [x] Tag the v3.9.0 release at this commit.
```
VERSION='v3.9.0' bash -c 'git tag -a "$VERSION" -m "$VERSION" && git push origin "$VERSION"'
```
[x] Open (but do not merge) PRs that do the following:
- [x] Update the documented version of Sourcegraph (example).
```
find . -type f -name '*.md' -exec sed -i '' -E 's/sourcegraph\/server:[0-9\.]+/sourcegraph\/server:3.9.0/g' {} +
# Or use ruplacer
ruplacer --go -t md 'sourcegraph/server:[0-9\.]+' 'sourcegraph/server:3.9.0'
```
- [x] Update latestReleaseKubernetesBuild and latestReleaseDockerServerImageBuild (example).
- [x] Update deploy-aws version
- [x] Update deploy-digitalocean version
- [x] Message @slimsag on Slack: 3.9.PATCH has been released, update deploy-sourcegraph-docker as needed
- [x] Update versions in docs.sourcegraph.com header (example)
[x] Review all issues in the release milestone. Backlog things that didn't make it into the release and ping issues that still need to be done for the release (e.g. Tweets, marketing).
[x] Verify that the blog post is ready to be merged.

By 10am PT on the 20th

[x] Merge the docs PRs created in the previous step.
[x] Merge the blog post (example).
[x] Close this issue.
[x] Close the milestone.
[x] Notify the next release captain that they are on duty for the next release. Include a link to this release issue template.
[x] Remind the team that they should submit retrospective feedback 24 hours before the scheduled retrospective meeting.

After the Retrospective

[ ] Scrub the retrospective Google doc for any priviledged customer data.
[ ] Convert to Markdown.
[ ] Add a new retrospective page in sourcegraph/doc/dev/retrospectives.
[ ] Add a link to it on retrospectives/index.md and in the left nav (sourcegraph/doc/_resources/templates/doc.html)
[ ] Update release tracking issue template with changes.

tsenart commented 5 years ago

Assign rows in the release testing grid to engineers from the team that owns the row.

@nicksnyder, @christinaforney: Is it safe to assume the current assignments are fine as they are or should we shift things around?

nicksnyder commented 5 years ago

@tsenart You don't need to recreationally move them around.

tsenart commented 5 years ago

Dear all,

This is your release captain speaking. 🚂🚂🚂

Branch cut for the 3.9 release is scheduled for tomorrow at 10:00 CEST.

Is this issue / PR going to make it in time? Please change the milestone accordingly. When in doubt, reach out!

Thank you

tsenart commented 5 years ago

Ping each team, and ask them to identify which of the optional rows that they own on the release testing grid should be tested this iteration.

@sourcegraph/distribution, @sourcegraph/core-services, @sourcegraph/code-intel, @sourcegraph/web: Please take a look at our release testing grid in Airtable and identify any optional rows you deem necessary to be tested this release.

Meta question: Has this step been resulting in actual optional rows being selected to be tested in previous releases or has the default answer been "no optional rows need to be tested"?

tsenart commented 5 years ago

Ping the @distribution team to determine which environments each row on the release testing grid should be tested in.

@sourcegraph/distribution: See above. How have you been doing this in previous releases?

beyang commented 5 years ago

Re: which columns, the column set has been stable for the past few release iterations, so no changes need to be made from 3.8 to 3.9.

Re: which optional rows should be tested for Distribution, I've added a row at the bottom to test the indexed-search migration to StatefulSet.

keegancsmith commented 5 years ago

The CHANGELOG section seems to have stuff from 3.8 in it, but I see at least one item for 3.9. That needs updating.

Meta question: Has this step been resulting in actual optional rows being selected to be tested in previous releases or has the default answer been "no optional rows need to be tested"?

No optional rows need to be tested from a quick scan. Yeah I agree with your assessment, but would want to hear back from more experienced release captains in the distribution team.

tsenart commented 5 years ago

Send a message to #dev-announce to announce the release candidate.

Announcement: https://sourcegraph.slack.com/archives/C0EPTDE9L/p1571132939025900

lguychard commented 5 years ago

No optional rows owned by web need to be tested.

tsenart commented 5 years ago

Status update:

There are 3 open release blocking issues: https://github.com/sourcegraph/sourcegraph/issues?q=is%3Aopen+is%3Aissue+label%3Arelease-blocker+sort%3Aupdated-desc+milestone%3A3.9
A new Release Candidate v3.9.0-rc.4 is out: https://github.com/sourcegraph/sourcegraph/compare/v3.9.0-rc.3...v3.9.0-rc.4

slimsag commented 5 years ago

Requesting the following changes are cherry-picked into 3.9:

[ ] 2e4860130475b27e14aa52ae01d8ab48454ccc16
- Author: @slimsag
- Reason: Improves a very frequent mistake power users can make with the new literal-search-by-default behavior.
[ ] d4e24b9fe2ccd8f444d9a2339ef42fbd1e0860be
- Author: @attfarhan @slimsag
- Reason: Improves a very frequent mistake power users can make with the new literal-search-by-default behavior.
[ ] ddaeeff411a88405620cc3a7cea214bffc4cc0aa
- Author: @slimsag
- Reason: Fixes two critical issues with paginated search API. Not strictly release blockers (nothing about paginated search API is), but very nice to have.
[ ] https://github.com/sourcegraph/sourcegraph/commit/3c647c173a07017fee050085258491992b425f89
- Author: @attfarhan
- Reason: Fixes a critical bug in d4e24b9fe2ccd8f444d9a2339ef42fbd1e0860be, so must be cherry-picked along with that change.

attfarhan commented 5 years ago

Also requesting these two small changes:

[ ] https://github.com/sourcegraph/sourcegraph/commit/bd512292ba84a37c4416713c53d2dd38dda30f73
- Author: @attfarhan
- Reason: Change in written copy in the literal search toast, which is shown to all users, including new ones (who were unaware of our past regexp default search), to be relevant to new users.
[ ] https://github.com/sourcegraph/sourcegraph/commit/c4ed2b5531acdc3504127666ea485a1d30acafb3
- Author: @attfarhan
- Reason: CSS change to make sure all Toasts/popups (popups, including the literal search one which is relevant to this change) are properly themed in dark mode

kzh commented 5 years ago

Requesting this bug fix to be cherry-picked into 3.9:

[ ] 9db8ad9
- Author: @kzh
- Reason: Bug fix to support zoekt symbol search for older indexes.

attfarhan commented 5 years ago

I noticed a bug on https://github.com/sourcegraph/sourcegraph/commit/d4e24b9fe2ccd8f444d9a2339ef42fbd1e0860be: this shows up for almost all queries that produce no results. I am going to push up a fix for it cc @slimsag.

Fix: https://github.com/sourcegraph/sourcegraph/pull/6100 -- added to @slimsag's list of commits to cherry-pick

tsenart commented 5 years ago

Alright, cherry-picking these and tagging the final release.

sqs commented 5 years ago

Merged blog post PR at https://github.com/sourcegraph/about/pull/286. There are some other announcement tasks outstanding (tracked in https://github.com/sourcegraph/sourcegraph/issues/5707) that I will ask someone else for help with tomorrow.

tsenart commented 5 years ago

Notify the next release captain that they are on duty for the next release. Include a link to this release issue template.

@beyang: I officially notify you that you're the 3.10 release captain as per https://github.com/sourcegraph/sourcegraph/blob/master/doc/dev/releases.md#schedule.

sourcegraph / sourcegraph-public-snapshot