If I understood your use case correctly, I think you’re deploying an application with it? I meant more about server configuration things with Ansible configuration which is version controlled and auto-applied on push.

In that case, say you are using Ansible to set up a daemon A on a server. Now you want to remove the setup for daemon A and move to daemon B. Just changing the configuration is not enough (since nothing stops daemon A and cleans up it’s configuration). And after you’re in the new state (let’s say daemon B was just an experiment), if you decide to revert the commit that added daemon B and push, nothing will stop daemon B.

I'm still not seeing the difficulty with doing that. Basically any daemons that you're setting up using distro packages or systemd service units (which, even though I'm not strictly in love with systemd, is what you should do for any service daemons you set up), it's just a matter of telling the service/systemd module and probably the copy or template module that you used to created the config files that they should be "state: disabled" or "state: absent" respectively. It'll disable and remove config of whatever service you've set up. What I will also do some times is create an array variable of services to enable and services to disable, and all that's required to switch is moving a daemon's name from one list to another. So, unless you're doing something outside of the modules like copying a bunch of stuff with the shell module and launching these putative daemons without some supervisor like systemd, it's pretty trivial to tell Ansible to reverse whatever it did. And if you are just launching processes using a bash script or something, why? It can get more complicated if it's e.g. a dev box and people are using ssh to go in and tinker directly, but generally Ansible will still just remove/create whatever needs to be there if it needs to be changed, or do nothing. Depending on how robust you want to make Ansible against people doing unexpected things, you can use trap doors like "meta: end_host" to bail out on errors if people are causing problems with manual edits, but that's better solved as a people/process problem than trying to make Ansible handle all possible unexpected situations.

In the end it's also usually just easier to use Ansible to bake a new VM or container configuration and deploy that instead of mutating an existing one over and over again.

If you move daemons from enabled to disabled, then you’ve taken an extra step. The difficulty is not in remembering to do it once, and daemons are a simple example. The difficulty is in always remembering, especially for trickier changes. But sure, if everyone always remembers, then it’s fine :)

I don’t think reversing what you just did is as trivial as it should be. For a git-based workflow to work well, it should be as simple as reverting a commit.

Setting up a VM from scratch is where Ansible is great. A CI/CD that recreates the VM and applies the config would work really well with automatic git deployment, but that’s generally not how people use it.

People have been chanting cattle not pets since before Ansible existed, so if people cargo cult it without using it in the way it's useful, there's not a tool out there that's going to really protect people from lack of due diligence. We don't judge a kitchen knife according to the people who try to grip it by the blade. Dependencies outside of an app's git repo will always exist for anything beyond the most trivial application.

Tooling can assist process, provide guard rails and reminders, but it's never going to replace remembering some important things. Having layers of process that mean that a single person forgetting is not going to cause disaster are necessary no matter what. Maybe when general AI exists we won't have to worry about remembering things, but then at best most of us will be out of jobs, at worst we'll be running from kill bots.

Don't get me wrong, there are plenty of design decisions in Ansible that regularly annoy me, but I've never expected it to make me less forgetful or substitute for people cooperating and communicating, and I think expecting any tool to do that is a road to disappointment.