> How about letting me just push php files via ftp to some outdated Debian machine. Cool, let's go with that. Which file are you going to push to which server

> How about letting me just push php files via ftp to some outdated Debian machine. Cool, let's go with that. Which file are you going to push to which server? I mean, you need to run integration tests to ensure everything works, but you'd be out of a job in no time if you ran those pointing to a production data store. Thus you better make sure you push that php file configured to point to a gamma stage data store. But after you ran those tests, you better promote those changes to production. Are you going to ftp that as well? You better not sneak a typo there. And bad luck struck and you broke prod when you ftp'd your php file to prod. How much time went on until you noticed it? And what's your plan to roll back that change? You better be damn sure about what php file you want to push this time around. With a CICD pipeline you do not have to do anything and the odds that you break a deployment because of a typo are terribly low. > All these layers of complexity made me swear never to touch "devops" again. Why not consider the problems that continuous delivery solve instead of put up a blanket ban on a methodology? Because with DevOps, you do not have to ftp any random file anywhere. You just push a commit to a mainline branch and your devops magic takes care of running unit tests + integration tests + end-to-end tests + canary tests to any stage, and automatically roll back any deployment that fails some test, without any interaction at all and before you know anything went wrong.