3 ms·

There's a reason most deployments moved away from that: - Sometimes you need more complex actions to update a service than just "update the code". Migration sc

There's a reason most deployments moved away from that: - Sometimes you need more complex actions to update a service than just "update the code". Migration scripts, dependent services restarts... - It's fine on one server, but the more you have the more difficult it gets - Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere. - Too easy to say "let me just modify this thing here in production" and end up with bug fixes that are only applied on certain machines and certain versions... I get the "let's do things in a simple way again" sentiment, but it's not like the complexity is there because people like complexity.

feoren 4y ago
> Too easy to say "let me just modify this thing here in production" This sounds crazy to me, like saying "it's too easy to say 'let me just poop on the floor right here' instead of going to the bathroom properly". What!? I can sorta vaguely understand why someone might think that's a little easier in the moment, but someone who has that little control of themselves needs serious help, if not a good old-fashioned kick out the door. That is not a technology problem, it's a human problem -- and a major one.
- gjulianm 4y ago
  The reality is that those things happen. Technology must inevitably deal with human problems too, it isn’t as easy as saying “just don’t do that thing”.
  - LAC-Tech 4y ago
marcosdumay 4y ago
> Sometimes you need more complex actions to update a service than just "update the code". Yes, software that was updated with a `git pull` always had an script or executable that gets the environment up to date with the new version. > It's fine on one server, but the more you have the more difficult it gets Nope, it's easy on as many servers as you want. It's just a matter of running `ssh $x (cd dir && git pull && dir/update_environment)` on a for loop. There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file. > Too easy to say "let me just modify this thing here in production" Well, that's a "don't". > Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere. And that is the one reason why this was abandoned almost everywhere, as soon as it became possible.
- gjulianm 4y ago
  > always had an script or executable that gets the environment up to date with the new version. Which means you’re writing deployment tools already. Going from there to an abstraction that provides the primitives you use in those scripts is a natural step. > There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file. Indeed. But again, this shows how deployment tools evolve naturally from “git pull” to something more complex. It’s not complexity for the sake of it. > Well, that's a "don't". If only managing computers was as easy as telling people what not to do.

feoren 4y ago

> Too easy to say "let me just modify this thing here in production" This sounds crazy to me, like saying "it's too easy to say 'let me just poop on the floor right here' instead of going to the bathroom properly". What!? I can sorta vaguely understand why someone might think that's a little easier in the moment, but someone who has that little control of themselves needs serious help, if not a good old-fashioned kick out the door. That is not a technology problem, it's a human problem -- and a major one.

gjulianm 4y ago
The reality is that those things happen. Technology must inevitably deal with human problems too, it isn’t as easy as saying “just don’t do that thing”.
- LAC-Tech 4y ago

marcosdumay 4y ago

> Sometimes you need more complex actions to update a service than just "update the code". Yes, software that was updated with a `git pull` always had an script or executable that gets the environment up to date with the new version. > It's fine on one server, but the more you have the more difficult it gets Nope, it's easy on as many servers as you want. It's just a matter of running `ssh $x (cd dir && git pull && dir/update_environment)` on a for loop. There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file. > Too easy to say "let me just modify this thing here in production" Well, that's a "don't". > Changes and dependencies accumulate on the server, which might cause weird errors or necessary configurations that aren't written down anywhere. And that is the one reason why this was abandoned almost everywhere, as soon as it became possible.

gjulianm 4y ago
> always had an script or executable that gets the environment up to date with the new version. Which means you’re writing deployment tools already. Going from there to an abstraction that provides the primitives you use in those scripts is a natural step. > There were plenty of tools to manage that loop too if you didn't want to keep the information on a simple text file. Indeed. But again, this shows how deployment tools evolve naturally from “git pull” to something more complex. It’s not complexity for the sake of it. > Well, that's a "don't". If only managing computers was as easy as telling people what not to do.