4 ms·
I'm working with a fifteen year old app that's slowly modernizing. There's two types of updates, the normal kind that's slow, and "everything is on fire, get th
by hyperpape 9y ago
I'm working with a fifteen year old app that's slowly modernizing. There's two types of updates, the normal kind that's slow, and "everything is on fire, get the fix into production ASAP, then pray". The latter kind is super quick, and it's what Equifax did here. But that doesn't mean patching is easy for them. It means patching without doing whatever laborious QA/manual testing they normally do is easy.
(Btw: it might sound like I'm defending Equifax. I'm not. I fully agree with the article. They have a responsibility to figure out how to secure their systems. "We can't patch quickly" may be true for them, but they needed to figure out how to change that).
- sqldba 9y agoYes. You've hit the nail on the head. They'll have such a tight bureaucracy on patching that it's impossible (which is an IT problem in their eyes) but the second a senior manager says just do it - its quick and painless. I see this over and over again everywhere.
- hyperpape 9y agoIt's quick, but it's risky, because testing is manual, you don't have blue-green deploys, etc. So it's not that it becomes painless, it's just that their are circumstances where you accept the risk.
- _asummers 9y ago> It means patching without doing whatever laborious QA/manual testing they normally do is easy. Everyone learns how to do Continuous Deployment when prod is on fire.
- hyperpape 9y agoIf you're not managing the risk of upgrades, you're arguably not really doing Continuous Deployment.