9 ms·

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 buildk

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

kjoedion 4y ago
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.
- endigma 4y ago
  https://fly.io/docs/flyctl/ssh/ https://fly.io/docs/flyctl/ssh/ https://render.com/docs/ssh https://render.com/docs/ssh ... and others
- bastardoperator 4y ago
  Say what? I can't tell if this is satire or not.
- deleted 4y ago
  [deleted]
matai_kolila 4y ago
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...
guhidalg 4y ago
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.
- endigma 4y ago
  Alternatively, learn how CI/CD works and have a comprehensive tool in your toolbox basically forever
  - guhidalg 4y ago
    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.
    - BlargMcLarg 4y ago
      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.
  - LAC-Tech 4y ago
    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?
    - outworlder 4y ago
deleted 4y ago
[deleted]
pcorsaro 4y ago
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.
datalopers 4y ago
> how actual software delivery is done the sheer arrogance and ignorance of this comment is remarkable
arasx 4y ago
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.
- cutler 4y ago
  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.
  - arasx 4y ago
    I normally would not want to comment short "I Agree"s. But this is music in my ears.
outworlder 4y ago
> 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.
- endigma 4y ago
  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.
- deleted 4y ago
  [deleted]
xani_ 4y ago
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 ?
- endigma 4y ago
  I could fit an entire droneCI/fly deployment setup in a single HN comment, no idea what you've been scarred by.
  - RaitoBezarius 4y ago
    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.
  - xani_ 4y ago
    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 ?
senorsmile 4y ago
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".

kjoedion 4y ago

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.

endigma 4y ago
https://fly.io/docs/flyctl/ssh/ https://fly.io/docs/flyctl/ssh/ https://render.com/docs/ssh https://render.com/docs/ssh ... and others
bastardoperator 4y ago
Say what? I can't tell if this is satire or not.
deleted 4y ago
[deleted]

matai_kolila 4y ago

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...

guhidalg 4y ago

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.

endigma 4y ago
Alternatively, learn how CI/CD works and have a comprehensive tool in your toolbox basically forever
- guhidalg 4y ago
  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.
  - BlargMcLarg 4y ago
    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.
- LAC-Tech 4y ago
  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?
  - outworlder 4y ago

deleted 4y ago

[deleted]

pcorsaro 4y ago

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.

datalopers 4y ago

> how actual software delivery is done the sheer arrogance and ignorance of this comment is remarkable

arasx 4y ago

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.

cutler 4y ago
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.
- arasx 4y ago
  I normally would not want to comment short "I Agree"s. But this is music in my ears.

outworlder 4y ago

> 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.

endigma 4y ago
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.
deleted 4y ago
[deleted]

xani_ 4y ago

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 ?

endigma 4y ago
I could fit an entire droneCI/fly deployment setup in a single HN comment, no idea what you've been scarred by.
- RaitoBezarius 4y ago
  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.
- xani_ 4y ago
  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 ?

senorsmile 4y ago

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".