Feature Request: More Robust Multienv push

[paulreimer]

THE PROBLEM(s)

1. When using the multienv (beta) support, I've noticed that it is TOO easy to accidentally get into a situation where e.g. env X settings get pushed to env Y (if for example amplify init is skipped when changing branches).
2. As well, it is made worse by the fact that before confirming the amplify push actions, an Update operation could refer to either "patch existing resource" or "delete-and-recreate resource" (yikes!).
3. Finally, there isn't a general, ALL CAPS warning when any delete operation happens to existing auth resources.

IDEAL SOLUTION(s)

1. I think it is a fundamental limit of the approach of coupling the envs to a git branch. I don't have a ready solution for the current approach, but other tooling would be more like amplify push --env production. Maybe this could be an optional argument anyway, so the amplify command would validate the env matches what was requested and aborts otherwise?
2. Hopefully it is possible to differentiate an Update that is "patch" vs "recreate" and communicate that to the user, and/or print a complete list of the resources that will be changed (not just "auth" or "hosting"), and whether each resource existed already?
3. I think a basic, dumb warning (or extra confirmation prompt) would help prevent a future disaster, as well (if necessary) an argument like --no-delete-warning to allow automated use but still indicate to script authors what (may) happen.

[paulreimer]

One other usability issue, I think related to multienv design being based on git branches -- it makes it hard to do operations in parallel to different envs, since only one branch can be checked out at a time. (e.g. "push-to-dev-env" and "delete-feature-sandbox-env" are things that I could do from different terminal windows, to save time).

[hisham]

+1. This is related to my feature request of some kind of 'dry run' or preview support so that we know exactly what cloudformation is going to do. See #366

[hisham]

As a workaround, for the delete-and-recreate resource scenario, I'm thinking of just adding an IAM policy restricting the user amplify cli is running under to not be allowed to delete critical resources like Cognito userpools and Dynamo DB production databases. I have not done that yet but I assume that will work and be a good fail safe.

[UnleashedMind]

@paulreimer @hisham
I marked 'feature request' for this issue.
We are working to improve the user experiences of the amplify-cli, thank you very much for your feedbacks.