Improve deploying env variables safely

[dkundel]

Right now the way we are deploying .env files intuitive if you deploy from your own machine but isn't really friendly for a CI/CD environment. Essentially you have to create a ".env.production" file and it could potentially contain secrets you don't want to expose. Especially for OSS projects.

I've been thinking about two options.

Option 1
The start command already supports a flag --load-local-env that loads all environment variables that are available on the system and provides them as env variables during local dev as backup for the ones in the .env file. We could add the same flag to both promote and to deploy but that would mean we would just take all of the environment variables we find, not giving you a fine grained control.

Option 2
We support basic "templating" in the .env file. That way you could have a .env.prod file that is checked into your repository but it looks something like this:

ACCOUNT_SID={{$TWILIO_ACCOUNT_SID}}
AUTH_TOKEN={{$TWILIO_AUTH_TOKEN}}
MY_PHONE_NUMBER={{$MY_SECRET_PHONE_NUMBER}}
GREETING=hello

This would swap out $TWILIO_ACCOUNT_SID, $TWILIO_AUTH_TOKEN and $MY_SECRET_PHONE_NUMBER with the respective system environment variables.

We could start introducing this as an experimental flag first and then fully ship it with the next major version. I think this gives folks a bit more control.

[dkundel]

The third option would be to give a flag that lets you pass environment variables one by one but they could pop up in logs again. So not viable

[dkundel]

After talking with @philnash the design we'll go with is a mix of the two options.

The behavior is the following:

If the user runs twilio-run deploy --load-local-env --env .env.production, the Serverless Toolkit will only load the system environment variables that also have a corresponding key inside the specified .env file (in this case .env.production). If --load-local-env is used without a --env flag, it will throw an error.

For the start command we will mimic the described behavior if both flags are passed. For compatibility reasons we will keep the currently start behavior if only --load-local-env is passed.