This message was deleted.
# general
s
This message was deleted.
t
Yes I have one. Our app originally had hard coded DB connection parameters (it was like that when I got here) and I accidentally connected to the prod DB from the staging environment and altered data in prod. Environment variables have since been used instead of hard coded credentials. Another issue (it was like that when I got here) is that prod and staging were in the same cloud account/project. That made it so prod cloud credentials were being used in lower environments. I can't remember if anything bad happened from that but we were just one innocent mistake away from wiping out prod data/infra. That's been addressed too. Different cloud accounts/projects for prod and each lower environment.
d
Don’t copy a staging database to production, unless you really need to because that awkward document you uploaded as a test during that weird QA Jira ticket investigation will cause some awkwardness for the Product Owner during a demo to the customer.
You might have to go to the customer and explain yourself. Take some biscuits with you.
Absolutely 1️⃣ the separation of credentials, including usernames (
x_dev_user
,
x_prod_user
), not just passwords
I’ve totally denied access to production because I was load testing a staging envionment before.
Think through the whole stack, like all the Jabbascript that has been added: staging analytics leaking in to production are really annoying. And the other way.
/website/production
and
/website/staging
on the same disk can be tempting, because 💰 🔌 💰 etc. But remember, you are just one fat finger chmod away from a really bad evening and awkward stand-up the next day.