Automatic deployment

[AlbertoPdRF]

Yesterday I was chatting with @jfly and we sort of came up with a plan to implement automatic deployment, which I'm documenting here:

• [ ] Fix the bugs/improve our deployment script so it doesn't need human intervention (link, link)
• [ ] Configure Travis so it automatically deploys the changes to the website after a PR is merged
  • @jonatanklosko already did that for https://github.com/thewca/wca-documents, so that should be a good starting point
• [ ] Track all the situations where people need to access the server after an automatic deploy to fix something, and address them
• [x] Update the admin? method so only WST's Leader and Senior Members are admins
  • This would include creating an admin@ G Suite group (removing it as an alias of software@) and syncing it with admins' email addresses only, and porting the secrets document to a Team Drives shared with admin@ only
• [ ] Protect master so PRs can only be merged after an approving review

Of course, we should move one step at a time: after the second point has been handled, we will run with automatic deployment for a month or two to see how it goes (i.e. third point) before moving forward with the fourth one. The last point is still something we need to think about if we want to implement.

[Jambrose777]

I marked the 4th bullet as complete since we have an admin sub-team: #6158.

[saranshgrover]

I would strongly suggest that if we do implement automatic deployment, we have a stage and prod branch, and follow this process for the stage branch to deploy to staging, and deploy to prod once every X days/weeks/months to avoid deployment to production over small fixes as well as having a good schedule for us to follow.

[gregorbg]

This should be easily possible using the deployment workflows from the private deploy repository. The biggest change here would be to implement the staging and production branches, although I totally like the idea in general!