4 ms·
I got tired reading that. How about letting me just push php files via ftp to some outdated Debian machine. All these layers of complexity made me swear never t
by rightbyte 5y ago
I got tired reading that. How about letting me just push php files via ftp to some outdated Debian machine. All these layers of complexity made me swear never to touch "devops" again.
- 3np 5y agoThe way I read the article, the “code” being talked about is not necessarily application code but the IaC used to provision the actual infrastructure. That is, the target audience is the sysadmin who would provision the PHP/FTP server and discussing how to sanely manage that as the fleet grows with slightly separate but mostly similar differences between instances. Maybe you as a web developer don’t want this complexity but a lot of it is inherent and someone has to deal with it at the end of the day.
- cyanydeez 5y agoi read it as semantic satiation. all hes done is change the terms, but you still have snowflakes because some system somewhere is cofiguring your snosflakes.
- joshuamorton 5y agoIf the snowflake is defined as class SnowflakeConfig(NormalConfig): # Normally this is 6, but for staging it has to be 2 foo = 2 and then you have something like deployments: us-east-1.prod: NormalConfig us-east-1.staging = SnowflakeConfig is it really the same? Granted, I don't think the article actually suggests that as a solution, so I don't think it provides a great response.
- Spivak 5y agoI mean modern devops is basically circling back around to that idea but with “php files” replaced with “git repo.” To deploy code to production at $dayjob all that’s necessary is to commit to master and press the play button once you’re satisfied the code works in dev/qa/staging. The pipeline is relatively complex because production ready infrastructure has some irreducible complexity but devs don’t have to care about it most of the time. In some cases we adopt a team of devs to work on infra related performance initiatives but that’s rare.
- fivea 5y ago> I mean modern devops is basically circling back around to that idea but with “php files” replaced with “git repo.” I don't agree. DevOps is and has always been a guy FTP'ing files to a server. Except that guy was smart and wrote a script that runs as a git hook to automatically run that for him. That script was so successful that the same figurative guy also integrated tests and checks and rollbacks into his script. After spending some time with the script, that guy noticed that the whole software development cycle would be far better if the software they were developing and deploying had some design features to eliminate potential problems and simplify said scripts. But in the end it's always a guy pushing files to a server. But doing it the smart way.
- ofrzeta 5y agoIt would be fine if you used programmatic scp instead of FTP I guess.
- fivea 5y ago> 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.