I don't think I've ever regretting setting up push-button deploys on a new project.
-
@polotek I am at the stage of startup life where I’m looking around for who’s supposed to be setting up deploys for me and realizing…I’m the only engineer sitting in the room
-
@rckenned good luck.
-
@polotek And setting up automated deploys is super awesome. Not even having to think about deploying feels great!
-
@evana lot of context required to unpack this. Generally I'm referring to server-based applications with centralized datastores. If the frontend is also web-based, it fits into this category as well.
Within that context. Bundling up a snapshot of code and pushing it to X number of production machines is table stakes. I would say that scripted database migrations is also necessary. Though I think it should be a separate action from code deploys.
-
@evana all the devils are in the details of course. Do you have a network layer that can drain traffic from old requests and ramp up new requests? Can you clear and warm caches to avoid thundering herds? A lot of other capabilities depends on your architecture.
-
@bencurtis it's nice early on when things are simple. But that can change quickly if the product is growing fast. I prefer to keep human eyes on what's going out. That's why I refer to push-button deploys. It still requires a human to initiate.
-
@polotek I've been thinking a lot about container and/or 12-factor environments (Cloud Run, Heroku, Kubernetes). Thanks for pushing me to think more broadly about deployment destinations!
-
@evana I think 12 factor is still super useful as a set of guidelines. We've gone way past what is practical in a lot of ways. I try to stay from from k8s. It's maybe useful once you get really big. But before that, it doesn't seem worth the headache.
-
@polotek “where is Knopp?” *looks around* “Shit…I’m Knopp now”
-
@rckenned we must all find our inner Knopp at some point in our lives.