Improve deployment workflow usability

[jemrobinson]

:white_check_mark: Checklist

• [x] I have searched open and closed issues for duplicates.
• [x] This is a request for a new feature in the Data Safe Haven or an upgrade to an existing feature.
• [x] The feature is still missing in the latest version.
• [x] I have read through the documentation.
• [ ] This isn't an open-ended question (open a discussion if it is).

:strawberry: Suggested change

We should ensure that our deployment workflow maximises usability for people who are new to the project.

Our current deployment workflow looks like this:

• dsh context add <KEY> --admin-group <group name> --location <location> --name <human friendly name> --subscription <Azure subscription name>
  • this creates a local context file (but nothing else)
  • I'm not sure it's clear that's all this command is doing
  • Are command line switches the best way to do this, or should it use a template (see #1720)?
• dsh context create
  • it's slightly unclear whether a Context is the textfile that describes which Pulumi backend you're using or the infrastructure deployed to use it. Perhaps it's both, but we should either separate the two or make it clear that they're the same thing
  • why create not deploy here (as for sre and shm)?
• dsh config template --file config.yaml
  • consider using e.g. copier (see #1720)
  • consider separating SHM and SRE configs (see #1777)
• dsh config upload config.yaml
  • the reason why the config needs to be uploaded is a bit opaque
  • it might be better to combine this with the next command by adding an optional --config argument to it
• dsh shm deploy
  • this command is simple but it's the first time we've mentioned the shm (all the previous steps were about a generic config)
  • as above, I suggest allowing an optional config argument: dsh shm deploy --config config.yaml
• dsh sre deploy <name of your SRE>
  • as above, I suggest allowing an optional config argument: dsh shm deploy --config config.yaml

:steam_locomotive: How could this be done?

There are a lot of steps in the above workflow, some of which are relatively mechanical and some of which we could give more help/guidance with.

Suggestion:

• dsh context add -> dsh context add/create but using e.g. copier to provide better templating
• ~dsh context create~ -> add a check in the deployment commands so that this is lazily created "on demand"
• dsh config template --file config.yaml use e.g. copier for templating
  • potentially this could also be the place where a context is created?
• ~dsh config upload config.yaml~ -> drop this
• dsh shm deploy -> dsh shm deploy --config config.yaml
• dsh sre deploy <name> -> dsh shm deploy <name> --config config.yaml

[JimMadge]

why create not deploy here (as for sre and shm)?

Good point, we need to at least be internally consistent

[JimMadge]

If the "current" SHM is removed, calling the context "SHM" could be quite sensible.

It is some infrastructure/data that is needed to manage SREs.