Tooling to better understand the main → .com/s2 lifecycle

Created by: varungandhi-src

One of the common problems when trying to land changes is that one often wants to answer questions like:

• This commit landed, has it already been deployed or what is an estimate for when it will be deployed? (For example, if some commit X requires manual rollout for a service, just using sg live and comparing ancestry with X is insufficient.)
• Does this commit require a manual rollout? If so, where are the docs on performing the manual rollout?

I don’t interact with the rollout/release process often, so ~every time I come back to it, I end up having to go through the docs to refresh my memory. However, the docs are explanation-oriented, not FAQ-oriented.

I did read the doc on Deploying a code change to Sourcegraph Cloud, and I’m glad that it exists (it has some broken links though), but I’m still not clear on if it is for both stateful and stateless services or if it is only for one of them.

I think this would be best solved by having an sg subcommand which can help answer the questions above.

(Moved from Slack thread)

In terms of S2 vs sourcegraph.com, Robert replied:

We are working towards de-emphasizing the need for dot-com, but this is something that we'll keep in mind as we get things going for s2

IMO, this makes the problem worse (and arguably necessitates tooling that does more), because now instead of the two questions above, you have the same questions but for each deployment point: S2 and sourcegraph.com. For example, if we're collaborating with an external entity, they don't have access to S2.