Hacker News Reader

Parent Full thread

quickthrower2

To avoid burning out I suggest:

1. Deploy

2. Test deployment

3. If success, great go home at 8:10pm.

4. If fail, rollback, retest, go home at 8:20pm. Come in next day and fix in source code and schedule new deployment.

5. To avoid #4 in 99% of scenarios, use a staging environment.

View on HN

In my experience staging environments only work in a few (very common) use cases. When I do big data work I certainly use a test environment but we can't just replicate all the data in two clusters because that would be absurdly expensive - and this makes testing performance basically only possible in prod. I'm sure basically any database system with a non-trivial amount of data has the exact same issue. But staging definitely works for something like a web server

Luckily we have "update nights" at most once every other month. But the workflow you describe is what I would want in the end. I work in a small startup tough so change is happening rapidly to make these processes better. It's far from institutionalized!

We do however have a staging environment already that is frequently updated and updates available within an hour from starting the update.

Thanks for the concern and tips nonetheless!

Reply on news.ycombinator.com