Yes, this. Cloning a git repo is not a reproducible build and deploy strategy, especially once you scale past one developer. Building a package (RPM/DEB/Docker container/whatever) once, and promoting it from dev through to test and prod, is. You are guaranteeing that the same code you wrote and tested is what is finally being deployed to production.

If the deploy process is "git pull", you're praying that Joe McGee didn't push some untested crap to the relevant branch 5 seconds before you deployed.

I'll argue with "that's how you know your system is reproducible and has everything it should and nothing else", though. To get there, you need to look at immutable infrastructure, where you're building a new container or VM image for every deploy. Otherwise you might have libfoo installed on the app server, despite your app dropping support for foo 2 years ago.

This is yet another problem. Joe McGee shouldn't be able to push in your master branch anyway.

You can use git for deployment but indeed you must have a clear commit policy to do that (and it's a good idea anyway to push only major curated versions on master).

Woah, that's not very kind! Some of these sites are run on a shoestring by sysadmins who are also juggling other issues, and it's hard for them to justify a brand-new deployment pipeline when the existing 'fput ~/code/the_web_site ftp://hosting/our_great_web_site' deployment costs nothing to maintain and works fine (sales/conversions are coming in).

And then you moved the problem from keeping your files in sync on the web server to keeping your files in sync on the package source.

That's a significantly more straightforward and safer problem to have to handle. You should prefer it across-the-board.

That's the exactly same problem, with the exactly same failure modes and consequences on failure.

It's also solved the exact same ways, by scripting your stuff on one level or another.

Solving the problem in one place (your CI/CD server) is a significantly less complex a task than solving it in N places (every server on which your application is running). It removes the concerns around configuration drift (have all your machines been properly brought up to policy?) and enables easier reasoning about the whole thing.

Building debs and rpms from version control is a legitimate step though.

Not necessarily.

You can actually use git in production, properly.

I personally like to mount gitRepo volumes on Kubernetes, and have my CI pipeline automatically update the revision of the deployment whenever it validates tests. Then I have kubernetes roll out the update automatically.