4 ms·

never, ever push changes on a Friday. I think this goes a little too far. I personally push code every Friday morning, and keep my Friday schedule relatively

never, ever push changes on a Friday. I think this goes a little too far. I personally push code every Friday morning, and keep my Friday schedule relatively open so I have time to deal with any surprises. Many successful companies brag (justifiably) about their continuous deployment systems and speed of deployment. I can't believe they suspend all of that every Friday. http://product.hubspot.com/blog/how-we-deploy-300-times-a-day http://product.hubspot.com/blog/how-we-deploy-300-times-a-da... https://github.com/blog/1241-deploying-at-github https://github.com/blog/1241-deploying-at-github https://www.wired.com/2013/04/linkedin-software-revolution/ https://www.wired.com/2013/04/linkedin-software-revolution/ https://www.facebook.com/notes/facebook-engineering/ship-early-and-ship-twice-as-often/10150985860363920 https://www.facebook.com/notes/facebook-engineering/ship-ear...

rak00n 10y ago
Pushing twice a day in that Facebook story gave me a shiver.
- prodigal_erik 10y ago
  Facebook legitimized the "move fast and break things" attitude by demonstrating that users don't care about reliability, at least nowhere near as much as some of us wish they did.
- mrep 10y ago
  If they were deploying to their entire fleet all at the same time, I would also shiver. However, most likely that have many stages in their deployment with testing and monitoring that exponentially deploys and if any of those stages don't pass, they auto-rollback. The End game: minimizing risk with code changes. 1. Deploying more often allows easier root cause analysis to identify the code breaking change. 2. exponential deployment allows developers to monitor their services as it partakes in more variation (more users = greater chance of edge case breaking bug) 3. proper monitoring and test coverage while using auto-rollbacks allows developers to deploy without fear as any unintended effects will be detected at the soonest possible moment while minimizing cost to the users of that breaking change. Then, auto-rollbacks will redeploy code changes that previously worked which should automatically mitigate that code breaking change.

rak00n 10y ago

Pushing twice a day in that Facebook story gave me a shiver.

prodigal_erik 10y ago
Facebook legitimized the "move fast and break things" attitude by demonstrating that users don't care about reliability, at least nowhere near as much as some of us wish they did.
mrep 10y ago
If they were deploying to their entire fleet all at the same time, I would also shiver. However, most likely that have many stages in their deployment with testing and monitoring that exponentially deploys and if any of those stages don't pass, they auto-rollback. The End game: minimizing risk with code changes. 1. Deploying more often allows easier root cause analysis to identify the code breaking change. 2. exponential deployment allows developers to monitor their services as it partakes in more variation (more users = greater chance of edge case breaking bug) 3. proper monitoring and test coverage while using auto-rollbacks allows developers to deploy without fear as any unintended effects will be detected at the soonest possible moment while minimizing cost to the users of that breaking change. Then, auto-rollbacks will redeploy code changes that previously worked which should automatically mitigate that code breaking change.