4 ms·
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 i
by quickthrower2 8y ago
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.
- opportune 8y agoIn 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
- catears 8y agoLuckily 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!