6 ms·
You'd probably find it easier when the deployed changes were extremely small. Our last automated deploy was a single line change. Most are bigger, but not huge.
by mrkurt 16y ago
You'd probably find it easier when the deployed changes were extremely small. Our last automated deploy was a single line change. Most are bigger, but not huge.
Also, while they don't do full rollbacks, I suspect more than one fix has been "remove the offending code until we can figure out what's wrong".
- Bolyuba 16y agoAgree, it seems to me that an emphasis is on time production deployment takes rather than rollback vs fix
- rm-rf 16y agoI've seen single line changes cause data loss, corruption, system outages, remote root exploits... I'm not sure that the number of lines makes the change more or less risky.
- ichverstehe 16y agoAnd how exactly does this relate to the way they deploy their code? As far as I can tell, they actually review code before marking it ready for deploy. That kind of changes would be an issue with "usual" large batch deploys as well.
- chaz 16y agoI've also seen many devs look at a broken release and instantly realize their mistake. A forgotten production config, a hard coded variable, or an empty cache. If code is in fact reviewed before going to production, the risk is significantly lower.
- cool-RR 16y agoNice choice of username, by the way.
- MartinCron 16y agoThe safest change to make to a stable system is the smallest change possible.