Hacker News Reader

Comment by endigma | Hacker News Reader

I don't see why the author is so proud of avoiding tooling that would make their build and deploy process simpler? Even something like digitalocean's own buildkit based "apps" would be an upgrade here. Deploying your app using ssh and git is not magic or simple it's just a refusal to learn how actual software delivery is done.

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

View on HN

> just a refusal to learn how actual software delivery is done.

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.

Way past senior engineer, not sure how git/ssh acrobatics is less complex in your mind than "fly deploy" or clicking a button in render/vercel/etc. Premade github actions / gitlab / all exist for these things and the author would be paying less money for a more robust deployment process. DIY with tools that aren't meant for the job isn't better because you already use git/ssh.

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 disagree, avoid CI/CD tools is the right call until this grows enough that you can't continue writing small scripts. I think all the CI/CD tools are garbage in that by being generic they do a poor job at addressing your specific needs.

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.

Alternatively, learn how CI/CD works and have a comprehensive tool in your toolbox basically forever

I'm not saying never learn CI/CD tooling, I'm saying don't use it until you need it. In an enterprise setting, yes it's probably a good idea to use such tools from day 1 because you don't ever want to be solely responsible for committing and shipping a bug. In other contexts, like the author's one-man website, the cost is not worth it.

You can't really say that without knowing the author's skills and how much they lose in opportunity costs to deploy manually.

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.

Are there any CI/CD tools that are likely to stand the test of time in the same way the basic unix ones have?

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?

No, they are all horrible monstrosities. The ones that are hosted by others (github actions) are still monstrosities, only that other people are taming the monsters.

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.

Alternatively

https://docs.dagger.io/1200/local-dev/ https://docs.drone.io/cli/drone-exec/ https://github.com/nektos/act

Jenkins/Travis are getting to this point, not that they are the "cutting edge" or anything. I'd personally rely on projects like woodpecker/drone/dagger so that there's no real "rely" on anything closed source or proprietary.

Well, our Jenkins jobs still work decade after. Jenkins itself requires some care and feeding tho, mostly upgrades, especially if you use some plugins.

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

Not every CI/CD tool is general purpose. I operate a small SaaS that runs on laravel. I have an incredibly simple CI/CD pipeline with static analysis and tests in GitHub Actions (one small workflow file) and Laravel Forge + Digital Ocean for infrastructure management and automated deployments from master. It took 5 minutes to set up and works perfectly

I've actually used OP's system in way higher traffic environments and was happy to read I was not alone. Sometimes all you need are simple tools and if git pull/ssh covers your basis, what's the big deal.

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.

I think what happens is some engineers invest so much of their professional identity in their Docker/K8s/Jenkins/AWS lifestyle that anything less is seen as dirty or inferior. The irony is that many of them are too young to remember the rationale for these tools when they were released, namely the management of massive fleets of servers by huge corporations. You see the same thing with the inappropriate use of React in the most minimally dynamic websites.

I normally would not want to comment short "I Agree"s. But this is music in my ears.

> how actual software delivery is done

the sheer arrogance and ignorance of this comment is remarkable

You're asking for net zero benefits at cost of adding hundreds of thousands of lines of code to your deployment path.

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 ?

I could fit an entire droneCI/fly deployment setup in a single HN comment, no idea what you've been scarred by.

No you cannot fit their whole tree of dependencies, their semantics and their failures modes in a single HN comment.

People use basic tools because they have much more understandable semantics, everyone do not need a gigaton pile of Go code to deploy something.

Calling include on someone's elses code is not programming nor ops no matter what lies you tell yourself.

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 ?

What?

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.

https://fly.io/docs/flyctl/ssh/

https://render.com/docs/ssh

... and others

Say what? I can't tell if this is satire or not.

I had a similar thought. If there was a little more automation here, that staging server could be shut down or even completely destroyed until the next testing/deployment window. The only reason I'd have multiple always on is to load balance for the same "color".

git push live is pretty simple I think. You're right that ssh and git aren't magic, and that's why the author is using them. I agree that they don't work in a team environment, but for a one man shop, I don't see why it's not OK.

AWS's CodeDeploy is magic for stuff like this. I got so many things for free when I began using it for deployments, it's kind of amazing...

Reply on news.ycombinator.com