6 ms·

> Handling everything from server procurement to FTPing the files to the server and even server maintenance. When I got back, this was "a big no-no" and mostly

> Handling everything from server procurement to FTPing the files to the server and even server maintenance. When I got back, this was "a big no-no" and mostly frowned upon. Everything was deployed by "git push" (fancy FTP?), While I do look back with nostalgia on the days of editing files in Notepad++, FTPing them to a live server, then quickly switching to my browser to refresh the page and make sure it works... Those days are in the past for a reason. No, git is not "fancy FTP". Yes, version control really does add much-needed structure to collaborative projects and change tracking. You can still run a small business web server on a colocated server and FTP files to it if you want. You just won't find any modern engineers who want to touch that with a 10ft pole. The world has moved forward since then, and for good reason.

withinboredom 4y ago
> No, git is not "fancy FTP" I was specifically referencing an old fad (might still be a thing but I haven't run into it in years) where production is a remote and a dev pushes their main branch to it to deploy. Yes, version control is amazing and it was something I used a bunch before my hiatus, but back then, it was usually SVN IIRC.
- PragmaticPulp 4y ago
  Using source control tools as part of the deploy process really is a valuable innovation. It's not an "old fad". I think you're clinging a bit too heavily to the "good old days". It's ironic how this entire thread has turned into a mix of people either 1) complaining that modern technology is too complex and complicated or 2) complaining that modern job applicants have lost the skills necessary to run things
  - withinboredom 4y ago
    That's an interesting take. But nah, I like some things the way they are now vs. back then. I love having cheap/easy CI that deploys to prod for me. I love having IDEs that are actually geared towards whatever language I'm writing in this year. I love having access to cheaper coloc space because most people aren't using it. I love having skills that most people don't even bother learning anymore when digging into performance issues. ... There is much I love about today and I look forward to the future. I was just stating my observations. And yes, `git deploy prod` is a fancy FTP, but probably even worse than FTP if the build actually happens on the production server (which is something I saw more than once) and causes a production outage (also saw more than once).
  - nonrandomstring 4y ago
    > complex and complicated Complexity is not a virtue. It is a dangerous resilience anti-pattern and should not be lionised. Unless you're insinuating that things in fact remain simple but the complaints of complexity are down to the stupidity of commenters.
  - nikau 4y ago
    > Using source control tools as part of the deploy process really is a valuable innovation. It's not an "old fad". Its only innovative in an 'Apple released it and now everyone is on the bandwagon' way. I've worked at companies that were using CVS for config file management in the 90s, the concept was already in play, it just wasn't as mainstream and didn't have a trendy infrastructure as code branding.
quickthrower2 4y ago
> Days of editing files in Notepad++, FTPing them to a live server, then quickly switching to my browser to refresh the page and make sure it works... If you just add local machine testing, and a test server to that mix, what is the problem?
nonrandomstring 4y ago
> and for good reason. Good reasons for some people. But it turned out that those reasons (which you avoid explicating) were not so good for some people after all. Methods upon which you now "look back with nostalgia" had value which endures, namely control, simplicity, low cost at small scale, and a basis in standardised, accessible knowledge. These things are not valued much any more, but it's my opinion (and of others) that is a mistake.
- sangnoir 4y ago
  > But it turned out that those reasons (which you avoid explicating) were not so good for some people after all. I lived through part of that transition - I'll try and explicate through my own experiences. The biggest thing automated deployments solved was human error. No more "oops, you forgot to FTP the JPEGs in binary mode" or "accidentally unploaded into a nested www/www folder". The transition was initially to tools like Ansible and Fabric which automated the transfer steps but had to be triggered manually. This also saved me a lot of time and pain. However, this still left a gap where it was still possible to push broken code into production, so Continuous Integration (and/or Continuous Deployment) became fashionable. The benefits of these were you'd never push code that fails tests to production, the depth and breadth of tests being left up to you. Incidentally, these developments coincided with my working with ever growing team sizes. There's no way I could have worked with 5 people with everyone S/FTP'ng stuff to prod. Neither would have Fabric + git been sufficient for four 5-engineer team working on the same software product. That's yet another benefit of the new way of doing things: it scales. I think the additional benefits of checking-in your configuration and deployment steps into a version control system are self-evident.

withinboredom 4y ago

> No, git is not "fancy FTP" I was specifically referencing an old fad (might still be a thing but I haven't run into it in years) where production is a remote and a dev pushes their main branch to it to deploy. Yes, version control is amazing and it was something I used a bunch before my hiatus, but back then, it was usually SVN IIRC.

PragmaticPulp 4y ago
Using source control tools as part of the deploy process really is a valuable innovation. It's not an "old fad". I think you're clinging a bit too heavily to the "good old days". It's ironic how this entire thread has turned into a mix of people either 1) complaining that modern technology is too complex and complicated or 2) complaining that modern job applicants have lost the skills necessary to run things
- withinboredom 4y ago
  That's an interesting take. But nah, I like some things the way they are now vs. back then. I love having cheap/easy CI that deploys to prod for me. I love having IDEs that are actually geared towards whatever language I'm writing in this year. I love having access to cheaper coloc space because most people aren't using it. I love having skills that most people don't even bother learning anymore when digging into performance issues. ... There is much I love about today and I look forward to the future. I was just stating my observations. And yes, `git deploy prod` is a fancy FTP, but probably even worse than FTP if the build actually happens on the production server (which is something I saw more than once) and causes a production outage (also saw more than once).
- nonrandomstring 4y ago
  > complex and complicated Complexity is not a virtue. It is a dangerous resilience anti-pattern and should not be lionised. Unless you're insinuating that things in fact remain simple but the complaints of complexity are down to the stupidity of commenters.
- nikau 4y ago
  > Using source control tools as part of the deploy process really is a valuable innovation. It's not an "old fad". Its only innovative in an 'Apple released it and now everyone is on the bandwagon' way. I've worked at companies that were using CVS for config file management in the 90s, the concept was already in play, it just wasn't as mainstream and didn't have a trendy infrastructure as code branding.

quickthrower2 4y ago

> Days of editing files in Notepad++, FTPing them to a live server, then quickly switching to my browser to refresh the page and make sure it works... If you just add local machine testing, and a test server to that mix, what is the problem?

nonrandomstring 4y ago

> and for good reason. Good reasons for some people. But it turned out that those reasons (which you avoid explicating) were not so good for some people after all. Methods upon which you now "look back with nostalgia" had value which endures, namely control, simplicity, low cost at small scale, and a basis in standardised, accessible knowledge. These things are not valued much any more, but it's my opinion (and of others) that is a mistake.

sangnoir 4y ago
> But it turned out that those reasons (which you avoid explicating) were not so good for some people after all. I lived through part of that transition - I'll try and explicate through my own experiences. The biggest thing automated deployments solved was human error. No more "oops, you forgot to FTP the JPEGs in binary mode" or "accidentally unploaded into a nested www/www folder". The transition was initially to tools like Ansible and Fabric which automated the transfer steps but had to be triggered manually. This also saved me a lot of time and pain. However, this still left a gap where it was still possible to push broken code into production, so Continuous Integration (and/or Continuous Deployment) became fashionable. The benefits of these were you'd never push code that fails tests to production, the depth and breadth of tests being left up to you. Incidentally, these developments coincided with my working with ever growing team sizes. There's no way I could have worked with 5 people with everyone S/FTP'ng stuff to prod. Neither would have Fabric + git been sufficient for four 5-engineer team working on the same software product. That's yet another benefit of the new way of doing things: it scales. I think the additional benefits of checking-in your configuration and deployment steps into a version control system are self-evident.