4 ms·
Canary deployments. Don't replace a production version, but install the new version next to it. Switch between versions via loadbalancer or use queues to decoup
by aequitas 6y ago
Canary deployments. Don't replace a production version, but install the new version next to it. Switch between versions via loadbalancer or use queues to decouple different implementations from storage. Adjust your development process to favor small incremental backwards compatible changes and feature flags (make deploying your code separate from enabling/disabling a feature). Lots and lots of monitoring and alerting.
- sitkack 6y agoLife finds a way. Within the boundaries of the space is a solution, we just don't know where the boundaries are most of the time. A bunch of years ago we were under a similar predicament, we needed to tune some software that was data dependent, yet we were cut off from prod data, and the test data as hot garbage. It took weeks to get new software into production. We had one code push left before launch but we still needed to tweak with production traffic. So we did what everyone does, ship remote firmware updates. In the last code push we included `eval` and the ability to POST code to an endpoint. We were just doing some query rewriting, but the code could have run anything. Once the last build made it through dev and test, we had a serverless deployment platform that allowed us to dynamically update the code in realtime. yolo