bob-bins
commented
5 years ago Test:
clone repo, check readme for dev cloud stack info, run cli, discover hostnames of running site, pulumi stack ui (if applicable) or other debugging ui (eg: gke dashboard for namespace, other helpful urls), validate it works, run test against it, update code / dockerfiles, cause update to existing environment, does not require all changes to be committed (but warns if they are not), can be destroyed on command, can be recreated after destroyed if needed (from same codebase / branch), automated test validates that, when a branch is pull requested, no dev-time environments for that branch are still actively deployed, and if they are, it fails with a clear message indicating it, a url to view it / administer it, and maybe a command that can be run to destroy it.
As a developer, In order to easily create, view, manage, debug, and destroy cloud environments during my iterative development process, I use automated scripts that, given I've provided my personal credential, consider my local branch, sha, uncommitted changes, etc. and deploy an environment based thereupon that I can further develop, update, and eventually tear down when my dev task is ready for PR or abandoned.