3 ms·
This sounds horrible unless they have a super reliable way to roll back changes to a consistent working state, both in their deployments and their databases.
by pmoriarty 5y ago
This sounds horrible unless they have a super reliable way to roll back changes to a consistent working state, both in their deployments and their databases.
- js4ever 5y agoAgreed, this sounds crazy. One argument raised is because staging is often different from prod. But their laptop are even more different. It seems the main goal was to save money. All this make sense only for a very small team and code base
- Msw242 5y agoHow much do you save? We spend like 3-4k/yr tops on staging
- nsb1 5y agoOr, on the flip side, how much do you lose by deploying an 'oops', resulting in customers having a bad experience and posting "This thing sux!" on social media? I can sympathize with the costs in both time and money to maintain a staging environment, but you're going to pay for those bugs somehow - either in staging or in customer satisfaction.
- lambda_dn 5y agoYou really need to use canary deployments/feature flags with this style. i.e. release to production but only for a group of users or be able to turn a feature off without another deployment.
- bradleyjg 5y agoApparently they never roll back, only forwards. That was elsewhere in the article. Sounds like a miserable idea. If you make a mistake and take down production you have to debug under extreme pressure to find a roll forward solution.