New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More explicit documentation for release process. #2185

Merged
merged 33 commits into from Feb 11, 2019

Conversation

@nicksnyder
Copy link
Member

nicksnyder commented Feb 6, 2019

We held a retrospective for the 3.0 release and the team unanimously requested that we strive to release more regularly. We did release regularly for most of 2018, but got derailed at the end of the year with our work towards 3.0. This PR is a plan to put us back on the rails.

"Regularly" could be defined in a few different ways (e.g. every third Tuesday of the month), but we have decided to adopt a fixed release date like GitLab.

The engineering question that this documentation aims to answer is "how do we consistently release on the 20th of each month"?

If this proposed documentation doesn't clearly answer that question for you, or if you have concerns about the process being documented, please ask questions or suggest edits that would help clarify.

We will discuss this during team meeting on Monday and I will plan to merge it by 4pm PT on Monday.

nicksnyder added some commits Feb 6, 2019

Revert "minor updates to roadmap"
This reverts commit ebcab8d.
@ryan-blunden

This comment has been minimized.

Copy link
Contributor

ryan-blunden commented Feb 6, 2019

This is awesome!

It was clear to me what the processes are, why they are the way they are, and the troubleshooting sections such as dealing with issues will save a lot of time and unnecessary threads on Slack.

And the release issue template is thorough and clear.

@tsenart
Copy link
Contributor

tsenart left a comment

Great to have this process shaping up so nicely! Good work! 🙇

Show resolved Hide resolved doc/dev/product/index.md Outdated
Show resolved Hide resolved doc/dev/product/index.md Outdated
Show resolved Hide resolved doc/dev/product/index.md Outdated
Show resolved Hide resolved doc/dev/product/index.md Outdated
Show resolved Hide resolved doc/dev/release_issue_template.md
Show resolved Hide resolved doc/dev/releases.md Outdated
Show resolved Hide resolved doc/dev/releases.md
Show resolved Hide resolved doc/dev/releases.md Outdated
Show resolved Hide resolved doc/dev/releases.md Outdated
Show resolved Hide resolved doc/dev/releases.md Outdated

tsenart and others added some commits Feb 7, 2019

Update doc/dev/product/index.md
Co-Authored-By: nicksnyder <nickdsnyder@gmail.com>
Update doc/dev/product/index.md
Co-Authored-By: nicksnyder <nickdsnyder@gmail.com>
Update doc/dev/product/index.md
Co-Authored-By: nicksnyder <nickdsnyder@gmail.com>
Update doc/dev/product/index.md
Co-Authored-By: nicksnyder <nickdsnyder@gmail.com>
Update doc/dev/releases.md
Co-Authored-By: nicksnyder <nickdsnyder@gmail.com>
@codecov-io

This comment has been minimized.

Copy link

codecov-io commented Feb 8, 2019

Codecov Report

Merging #2185 into master will decrease coverage by <.01%.
The diff coverage is n/a.

Impacted Files Coverage Δ
...nterprise/cmd/frontend/auth/httpheader/provider.go 0% <0%> (-16.67%) ⬇️
...prise/cmd/frontend/auth/httpheader/config_watch.go 87.5% <0%> (-12.5%) ⬇️

nicksnyder added some commits Feb 9, 2019

Show resolved Hide resolved doc/dev/releases.md Outdated
Show resolved Hide resolved doc/dev/releases.md Outdated
Show resolved Hide resolved doc/dev/releases.md Outdated
Show resolved Hide resolved doc/dev/releases.md Outdated
Show resolved Hide resolved enterprise/cmd/server/README.md Outdated
@slimsag

slimsag approved these changes Feb 9, 2019

Copy link
Member

slimsag left a comment

I left suggestions inline, but nothing blocking. I like this a lot.

@vanesa

vanesa approved these changes Feb 9, 2019

Copy link
Member

vanesa left a comment

With the proposed changes from our teammates, I think this is good to go. Thank you @nicksnyder for writing down the release process in such a clear way.

slimsag and others added some commits Feb 11, 2019

Update doc/dev/releases.md
Co-Authored-By: nicksnyder <nickdsnyder@gmail.com>
Update doc/dev/releases.md
Co-Authored-By: nicksnyder <nickdsnyder@gmail.com>
Update doc/dev/releases.md
Co-Authored-By: nicksnyder <nickdsnyder@gmail.com>
Show resolved Hide resolved doc/dev/release_issue_template.md Outdated
Show resolved Hide resolved doc/dev/release_issue_template.md Outdated
Show resolved Hide resolved doc/dev/release_issue_template.md Outdated
Show resolved Hide resolved doc/dev/release_issue_template.md Outdated
- [ ] Go to definition works in TypeScript.
- [ ] Find references works in Go.
- [ ] Find references works in TypeScript.
- [ ] Run Sourcegraph on a clean Kubernetes cluster with no previous data.

This comment has been minimized.

@ggilmore

ggilmore Feb 11, 2019

Contributor

Should we link to https://github.com/sourcegraph/deploy-sourcegraph/blob/master/README.dev.md and/or modify it to de-duplicate information?

This comment has been minimized.

@nicksnyder

nicksnyder Feb 11, 2019

Author Member

This checklist should be the canonical checklist for releasing Sourcegraph. It is ok if it links to other docs for certain steps (e.g. how to run Sourcegraph on a clean Kubernetes cluster), but we should avoid duplication anywhere.

Parts of https://github.com/sourcegraph/deploy-sourcegraph/blob/master/README.dev.md are duplicated and should be removed. There is one part (an update to deploy-sourcegraph that doesn't involve bumping image tags) that probably needs to stay documented there and not here.

Show resolved Hide resolved doc/dev/releases.md Outdated
Show resolved Hide resolved doc/dev/release_issue_template.md Outdated

## Releases are monthly

We ship a release on the 20th day of each month. (Except in February 2019, where we will ship on the 4th and 20th.) Why the 20th? Because it's a day number that we can hit each month (any other number would result in a December release that comes out too close to Christmas, or a January release that comes out too soon after New Year's Day).
We release Sourcegraph by 10am PT on the 20th day of each month. No exception is made for weekends or holidays.

This comment has been minimized.

@ijsnow

ijsnow Feb 11, 2019

Contributor

I was going to add this during the meeting but it's more of a nuetral/non-argument and I didn't want to interrupt the discussion:

Before this meeting, I was on the side of releasing on the 3rd tuesday every month because of the prospect of us having to do work on weekends. But if the work of the release captain is to do all of the steps "on or before" the release date, and that means it would be fine to do all the final work for the release on the 18th if the 20th is a monday AND a holiday, then there's not real difference between whether we release on the 20th or the 3rd tuesday. The fact that our end goal is for the release is to be a "non-event" and ideally automated away in the future also supports this opinion. Since it should be a "non-event" and the work can be done before the release date in the mean time, I think we should go with the option that takes less thought, which is IMO releasing on a fixed date (though the difference is pretty small).

This comment has been minimized.

@nicksnyder

nicksnyder Feb 11, 2019

Author Member

Thanks for sharing your thoughts!

After re-reading this, I think the "no exception is made for weekends or holidays" is somewhat redundant so I am going to remove it.

nicksnyder added some commits Feb 11, 2019

Apply suggestions from code review
Co-Authored-By: nicksnyder <nickdsnyder@gmail.com>

nicksnyder added some commits Feb 11, 2019

@nicksnyder

This comment has been minimized.

Copy link
Member Author

nicksnyder commented Feb 11, 2019

Based on the discussion during team meeting today, some people remained unconvinced that releasing on a fixed day each month is actually better for customers than a relative date (e.g. "third Tuesday of each month").

The biggest remaining concern is that will not be as responsive to issues raised immediately after release to the extent that we release on or right before the weekend. It is factually true that our capacity to respond to issues is much less on the weekends, but it is not obvious whether releasing on/before the weekend will actually result in more issues being filed on the weekend. I also think customers would understand if we don't respond until Monday. Regardless of when we release, we don't control when customers actually install/update. For example, I remember at least one instance of us releasing early in the week only to have a customer attempt an upgrade on Friday evening (and run into issues). This is an area that we can continue to discuss.

For 3.1, it would be counter productive to change the release date that we already agreed on (the 20th). Given that, we do need a release process for that release, and this PR contains such a release process that we can try. I expect this process to be refined and evolve as we perform more releases and learn what does/doesn't work.

@nicksnyder nicksnyder merged commit 318feab into master Feb 11, 2019

1 check passed

buildkite/sourcegraph Build #27720 passed (5 minutes, 4 seconds)
Details

@nicksnyder nicksnyder deleted the releaseprocess branch Feb 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment