4 ms·
Syntax errors are the easiest errors to fix and almost never get into production. Zero downtime deployments are very rare, and ads a lot of complexity, so it's
by z3t4 7y ago
Syntax errors are the easiest errors to fix and almost never get into production.
Zero downtime deployments are very rare, and ads a lot of complexity, so it's a big trade-off, compared to just uploading the new code and restarting the service. And having the front-end deal with minor hiccups like service restarts, because users will have such issues all the time due to being on mobile networks, trains going through tunnels etc.
You can do as much testing as you want, both manually and automatically, but you still can't detect all issues as efficient as thousands of users in production. So just accept that there will be issues, and instead design your pipeline so that those issues can be fixed within minutes.
- quickthrower2 7y ago> You can do as much testing as you want With what Dark is promising, I believe testing would be easier. Deploy to a test environment in 50ms. Then run a suite of tests, then deploy to production in 50ms. There could be some complementary tech that figures out what tests need to be run based on what you change to get the time down.
- heavenlyblue 7y agoThey're kind of lying. You only need pip or any package install if your testing image doesn't pre-install the required packages before running the tests. Which I don't myself since I always want to see if my packages work with the latest versions of other packages - and Dark wouldn't be able to handle that anyway. So my test runs actually complete in about 50 ms if I'm not testing any external API functionality. They will also never finish earlier than 5 minutes if I am, even on Dark - since they're based on external services.
- snypox 7y ago> Zero downtime deployments are very rare What do you mean? Rolling deployments are a very basic feature of container orchestrators.
- nijave 7y agoYou don't even need containers--it's a feature of load balancers containers rely on. Start new container, wait for it to become healthy, add it to the load balancer, remove old container (with an optional, let connections to old container close first)
- PunchTornado 7y agowhat if it involves db updates?
- rblatz 7y agoWhere I work we had that same thought. Until we stopped doing breaking database changes.
- sethammons 7y agoWe have run a lot of db changes. It requires multiple steps. Add a column, migrate data, update code to use new column and old column, update code to use only the new column, update table to drop old column. Similar for migrating to new dbs, tables, etc. It is rare for us to need to disable writes for a version bump or something.
- z3t4 7y agoIf you aim for zero downtime there will be a point where the complexity work against you. for example: load balancer goes down, corrupted state due to two different versions running simultaneous, a bottleneck causing congestion, etc. My favorite "load balancing" for web-pages is using "DNS round robin" where you add several A records, and the browser automatically try another IP if the request fails.
- nicolaslem 7y ago> ...the browser automatically try another IP if the request fails. The browser tries another IP if it cannot connect to the first one. If a server throws 500s left and right DSN RR won't help, whereas a load balancer would remove the offending server from the pool.