3 ms·
"Both cloudformation stacks were identical (instance names, etc)." This is why it's a good practice to include the environment name in the resource names when
by ahoka 6y ago
"Both cloudformation stacks were identical (instance names, etc)."
This is why it's a good practice to include the environment name in the resource names when it makes sense. Even better, don't append the env name, but use it as a prefix, like ProdCustomerDb instead of CustomerDbProd. I also like to change the theme to dark mode in the production environments as most management UIs support this. One other neat trick is to color code PS1 in your Linux instances, like red for prod, green for dev.
- greedo 6y agoI have my background colors configured for each environment so when I'm shelled into a server, I know exactly what I'm working with.
- brlewis 6y agoI'm too lazy to do this manually for each server, but I change the hostname color in my prompt based on its hash. https://gitlab.com/brlewis/brlewis-config/-/blob/master/bash/ubuntu.sh#L36 https://gitlab.com/brlewis/brlewis-config/-/blob/master/bash...
- nitrogen 6y agoOne other neat trick is to color code PS1 in your Linux instances, like red for prod, green for dev. This is definitely a nice one to add. Though I did work with someone once who believed that all servers should be 100% vanilla and reverted my environment colors. In container-only shops with no ssh, this is less of an issue, and instead you rely on having different permissions and automations for different environments.