One day you will be promoted to 'senior engineer' and revise this statement.
Software exists to solve problems. Adding more complexity has to serve a purpose. Just because you read somewhere that Netflix does their deployment in some way, doesn't mean that it's the right way for your environment.
The only thing I disagree with his approach is that they do "ssh <host> git pull". They should just "git push <host>" from their CI machine(or laptop since they have no CI/CD). No reason to allow access to code from the actual server and git is distributed.
They could surely turn off the non-active server but they might be using that for failover. In that case serving zero requests is totally fine.
Author is running gunicorn/flask/nginx, this is trivial for a buildpack and would take like 5-10 minutes tops to set up a robust build/deploy flow with any recent PaaS.
I don't know who needs to hear this, but you don't always need to start a project by reaching for the most complex tool possible. Build up to it and then you won't need convincing to use it.
If the author has already deployed 100-200 times and knows enough to set up a basic build, it would be close to break-even with a fairly wide margin.
I'm not against making things easier. But I feel like it's so easy to over-engineer and rely on proprietary crapware.
Is there a conservative path forward here?
Then again jenkins job can be as simple as "download a repo and run some code in it" without anything fancy so even if SHTF you can migrate away relatively painlessly
The best way I've found is to keep the CI/CD tools as just simple task runners. They should only have to figure out when to run things, inject the necessary environment(and secrets), and figure out dependencies (if applicable) and run those. Whatever they run, you should be able to run the same scripts from your own laptop or a similar.
How actual software delivery is done is a relative term to the systems/needs and the scale you have. You probably have not been in environments where build/deploy tools are over engineered to death, to the point where adjusting it one bit brings down the entire delivery to a halt. If you were able to set those up without such issues, kudos to you.
the sheer arrogance and ignorance of this comment is remarkable
That really smells of desperate developer that need to feel relevant just because they use the latest thing
Like, how the fuck it would be "simpler" if the deploy is literally just running a single script ?
And we use CI for 12 years and yes, our node definitions can also fit in your utterly idiotic metric
Want to tweet "our app is so small you can just npm get it" next ?
People use basic tools because they have much more understandable semantics, everyone do not need a gigaton pile of Go code to deploy something.
Manual git pushes ensure the highest level of security and error avoidance.
I routinely find myself having to do one-off post-deployment things that would be a nightmare to try and script into the ci flow.
Even totally dodging docker/k8s/nomad/dagger or anything that's even remotely complicated platforms like AWS/DO/Fly.io/Render/Railway/etc obsolete this "simple" approach with nothing but a config file.
I also theorize that the author is likely wasting a boatload of money serving ~0 requests on the staging machine almost all the time, due to him literally switching a floating IP rather than using two distinctly specced machines for production and staging