[nickjj]

I tend to agree with this pattern as long as the commands you're running let you explicitly state which environment you're running these commands against so there's never any confusion by the human running the commands or the human reviewing CI logs.

With Kubernetes / Helm you can have all of your resources named the same in each environment, each with their own set of same named env vars that follow what you've described but whenever you do anything that interacts with your cluster you can add a `-n prod` namespace flag so that each environment runs in its own isolated namespace.

Also for good measure it's not a bad idea IMO to add _dev, _test, _prod to the name of your database just as a double identifier. It still meshes well with the strategy of using a DATABASE_URL. I like using the full URL instead of just using the DATABASE_HOST since the password will be different across environments and I'd rather only have to set 1 env var instead of 2+.

In a sibling comment someone mentioned this pattern doesn't work for monitoring in different environments but it does work. You can set an APP_ENV env var and then filter based on that. The same thing applies for logging. You can tag / filter your logs on the APP_ENV too.