41–50 of 54 posts
I'm less enthused about 'rollbacks' being considered 'normal'. They signify something didn't go quite right with your unit/integration/qa process. IMO there should be at least a 'mini-postmortem' to understand why it was missed even if it's in an intentional blind spot. (i.e you made an explicit decision it wasn't worth the engineering resources to get the testing fidelity needed to catch the issue earlier). It's alm…
I'm less enthused about 'rollbacks' being considered 'normal'. They signify something didn't go quite right with your unit/integration/qa process. IMO there should be at least a 'mini-postmortem' to understand why it was missed even if it's in an intentional blind spot. (i.e you made an explicit decision it wasn't worth the engineering resources to get the testing fidelity needed to catch the issue earlier). It's alm…
[Deleted because I'm being a dickhead, and can see that]
> any reliable software release is being able to roll back if something goes wrong; we discussed how we do this at Google ... How we do this at Google? Okay, tell me how to roll back the crap Android 6 upgrade back to 5 on this Samsung tablet I have here.
Continuous automated deployments might not be a great fit for satlellite control software but that doesn't mean SaaS apps should switch to the same process as satellite software teams.
I'm less enthused about 'rollbacks' being considered 'normal'. They signify something didn't go quite right with your unit/integration/qa process. IMO there should be at least a 'mini-postmortem' to understand why it was missed even if it's in an intentional blind spot. (i.e you made an explicit decision it wasn't worth the engineering resources to get the testing fidelity needed to catch the issue earlier). It's alm…
While I agree on your points that it is better to catch errors earlier in the pipeline and the necessity of mini-postmortems, I personally think that rollbacks are inevitable and compare them to backups. Of course it is better not to restore from backups, it is easy to rationalise good processes over a few metric tons of never been read backup tapes, but a single accidental drop of production database may quickly pay for all the effort put into ensuring backing up works.
I wouldn't take this advise as it's bad for caching. A change to one JavaScript file will then result in breaking the cache of everything.
> One solution is to version your JavaScript files (first release in a /v1/ directory, second in a /v2/ etc.). Then the rollout simply consists of changing the resource links in your root pages to reference the new (or old) versions. I wouldn't take this advise as it's bad for caching. A change to one JavaScript file will then result in breaking the cache of everything.
> One solution is to version your JavaScript files (first release in a /v1/ directory, second in a /v2/ etc.). Then the rollout simply consists of changing the resource links in your root pages to reference the new (or old) versions. I wouldn't take this advise as it's bad for caching. A change to one JavaScript file will then result in breaking the cache of everything.
Maybe I misunderstand, but don't you want to invalidate the cache when a new version comes along? Isn't the risk of version skew worse?
Earlier quoted context omitted.
Maybe I misunderstand, but don't you want to invalidate the cache when a new version comes along? Isn't the risk of version skew worse?
If one.js changes but two.js doesn't, then two.js should come from the cache. Only one.js should be fetched from network. Sticking all assets in an /assets/v2 folder invalidates everything .
Earlier quoted context omitted.
That's not a drawback so much as it's a fact of life. In any large-scale (read: distributed) system trying to provide a high degree of availability, rolling upgrades are the only way code goes out and individual components need to deal with interacting with newer/older dependencies. You can constrain the matrix by only allowing current version plus one back running in production, or forcing deployment orders, and so…
Another approach is you start up a full copy of the new system with all new versions, then change loadbalancers to direct all traffic away from the old system and to the new. Then decomission the old system. With dedicated hardware, you need twice as much hardware. With cloud, you only pay double for 10 minutes during the rollout, which usually is very cheap.
Earlier quoted context omitted.
Maybe I misunderstand, but don't you want to invalidate the cache when a new version comes along? Isn't the risk of version skew worse?
If one.js changes but two.js doesn't, then two.js should come from the cache. Only one.js should be fetched from network. Sticking all assets in an /assets/v2 folder invalidates everything .