Local deploy commands should run on release-branches/

[zepumph]

From #363, @samreid @jonathanolson and I had an idea to try to get rid of the need for perennial-alias by using the release-branches/ strategy used by maintenance tooling and the build server. The general goal of this would be to one day have no perennial build commands that require changing shas in the main checkout, but that seems like a giant project, and so we just want to experiment.

The commands that feel most important to change (to MK) are:

• rc
• production
• one-off
• maintenance commands like ReleaseBranch.checkoutBranch()

We have scheduled a meeting to investigate for next tuesday.

[zepumph]

@samreid and @jonathanolson and I had a conversation today about this in regards to #363. Ideally we were trying to brainstorm a simple and cheap way to get rid of perennial-alias. Basically to get rid of perennial alias, all operations that could change perennial's sha would need to instead be done in a nested/side checkout. We are finding that is really challenging to conceive of all git operations that perennial can do being instead done outside of the main checkout. For example, grunt checkout-timestamp uses multiple commands in js/common/ that assume ../${repo} in the path for the checkout/status/pull etc.

We do not, at this time, recommend trying to remove the dependency we have on perennial-alias.

Through this though, we do feel like recognizing a shift in perennial's design, where we don't prefer git commands on the main checkout, and first see if it is an implementation detail that can be hidden in release-branches/. For example, grunt rc will build from your main checkout. This isn't necessary, and leaves you without a codebase to work on while the task is going (3-10 minutes). If it was done in a sub checkout, it would be faster (no need for drastic npm update changes), and simpler for the developer running the command.

Let's experiment with using ReleaseBranch() for rc/production/one-off and see how it goes.

Also, @jonathanolson had an idea that this could be a stepping stone for having a Checkout class, a supertype of ReleaseBranch that could act upon any arbitrary checkout of repos. This could be used by something like checkout-timestamp even to operate on the main checkout.

class Repo{
  string pathToRoot;
  string name;
  async checkoutSHA(){}
  async checkoutMain(){}
  async checkoutBranch(){}
  async pull(){}
  async status(){}
}

class Checkout{
  string pathToRoot;
  dependencies: Record<RepoName,Repo>
  checkoutShas(){}
  update(){} // clone/checkout/npm/etc
}
class ReleaseBranch extends Checkout{
  repo: string;
  branch: string;
  build(){}
}