Best Practices, aka splitting staging from production

Rack (Version 2)
1

Does anyone know the reason for the best practice advice of creating separate racks for staging and production?

We’re now refactoring our early days of convox usage and the overuse of racks. One per environment, per team. We’re considering moving to one rack for all of our application environments, and one rack to test rack configurations and upgrades only.
I’m curious as to the reason for separating into separate racks per environment when containerization is essentially handling this for you?

2

Quick question: could you please point out to the best practice recommendation for separate racks for staging and production? Thank you.

3

It’s in the right sidebar of the web console under the racks tab.

Best Practices

We recommend creating separate Racks for staging and production so that you can verify applications before they go live.

4

Thanks @buckley :+1:

5

I think the usual way to do this (at least for small scale companies) is to have one production rack and one staging rack, and deploy your apps on both racks (first on staging, then on production). Your staging apps won’t mess up with your production apps, and you can test infrastructure changes on a separate rack before applying to production.

I.e. the strategy you came up with after your rack overuse. Even if the apps are containerized, you still want to be able to test changes in a non-production rack first.