3 ms·
> If you were to get rid of staging would you stand up your entire backend every time you made a preview environment? Does that include replicating databases or
by andrewmutz 4y ago
> If you were to get rid of staging would you stand up your entire backend every time you made a preview environment? Does that include replicating databases or would you just use seed data that may or may not resemble what's in production?
What I've seen done is that the staging environment is skipped, but instead concentric releases are performed on the customers. So released code goes first to a small group of users, and then widens from there if everything looks good.
- oasisbob 4y agoThis technique doesn't seem especially relevant for many kinds of backend work.
- scubbo 4y ago> What I've seen done is that the staging environment is skipped, but instead concentric releases are performed on the customers. So released code goes first to a small group of users, and then widens from there if everything looks good. If you really want to invest in extensive testing, you can do both! Hell, _and_ you can have a load testing environment as well.
- andrewmutz 4y agoYeah, we had tooling to load a snapshot of customer data (with PII removed) into an ephemeral environment for when developers needed data that was more authentic. This worked for performance related work or just for features that needed a complex data model to be useful (ML apps, etc)
- klooney 4y agoSchema changes are hard to roll out that way though.
- andrewmutz 4y agoWe were a B2B product whose multitenancy model was schema-per-customer, so it was no problem for us. Agree that it would be harder to implement with customers sharing a schema, but you can still have different release pods