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