4 ms·

For both of your interrogation, old fashioned PHP devs used to (and I do not doubt that some still) deploy that way.

risratorn 14y ago
To be honest, most of them do so because it's the only option present on most shared hosting platforms. (S)FTP is for most of us the only option when deploying a simple site to the client's hosting. Ofcourse it would be cool if all of our clients would host on a PAAS platform like Orchestra or PHPFog but that's not the case by a long shot i'm afraid.
damncabbage 14y ago
A year and a half ago I worked at a place that had a Deployment Spreadsheet. Each file was carefully FTP'd from the shared development area to the live site, and then marked off on the sheet with the date that it had been deployed, and with what feature. Each new deployment meant either adding a new set of rows to the spreadsheet for a new feature, or for updates to existing features going back and finding an earlier instance of the file in the list and bumping the date on that. Because of the shared nature of the CMS across different websites, we couldn't svn up in the CMS directory without destroying the current known state of the site. We also couldn't svn up outside of the subdirectory we were working on, as everyone else working on that site was working off the same network share. Everything was done very gingerly. The day one of the developers came up with a method to take a list of files from the spreadsheet, tar them up and FTP them to the server for later extraction, he was overjoyed and very, very proud. I got out of there, swore off PHP and its community entirely. I got tired of checking for a baseline of automated deployment, automated testing, version control, and individual dev systems at every single job I applied for; Ruby people don't look at you funny when you mention these things. Addendum: I personally know a developer currently working for a famous local radio brand who directly works on the live website network via an FTP plugin. He has to contend with other developers dumping the contents of archives directly into his public folder. (For context, this is all in Sydney, Australia.)
- acdha 14y ago
  FWIW, this is essentially how Oracle ships updates for their enterprise business systems: you get a tar file and a README telling you which files get copied to which spots on which servers.
- dredmorbius 14y ago
  If you can every track me down in real life, I'll buy you a misery beer.
  - damncabbage 14y ago
    Haha, thanks. :-)
- sauravc 14y ago
  That shitty deployment experience has nothing to do with PHP. There are plenty of valid reasons to move to Python or Ruby, but better deployment stories aren't one of them. Objectivity seems to be in short supply here on HN.
  - heretohelp 14y ago
    It has to do with community standards. The community standards for deployments and dependency management for Python & Ruby are much higher than PHP. virtualenv/rvm are the standard, using git is the standard, fabric/capistrano for pushing/provisioning is standard. This is not the case for PHP, the vast majority are using graphical FTP clients to manually overwrite files.
  - AnswerAndForget 14y ago
    Isn't the ecosystem always trotted out while defending PHP, as well as its 'accessibility' to amateurs? Well, those amateurs are part of the PHP ecosystem, and you'll have to put up with that... or not.
  - damncabbage 14y ago
    heretohelp made the point better than I did, but I explained my thoughts on that with this sentence: I got tired of checking for a baseline of automated deployment, automated testing, version control, and individual dev systems at every single job I applied for; Ruby people don't look at you funny when you mention these things. It's about expectations. I tried really hard to find a place that had all these in the PHP world. In the Ruby world (for example), it's a given. (I have only ever encountered one PHP shop during my rounds interviews that did automated testing... But they used CVS for version control. The very first Ruby shop I interviewed had all of the above, and treated it like they were no big issue.)

To be honest, most of them do so because it's the only option present on most shared hosting platforms. (S)FTP is for most of us the only option when deploying a simple site to the client's hosting. Ofcourse it would be cool if all of our clients would host on a PAAS platform like Orchestra or PHPFog but that's not the case by a long shot i'm afraid.

damncabbage 14y ago

A year and a half ago I worked at a place that had a Deployment Spreadsheet. Each file was carefully FTP'd from the shared development area to the live site, and then marked off on the sheet with the date that it had been deployed, and with what feature. Each new deployment meant either adding a new set of rows to the spreadsheet for a new feature, or for updates to existing features going back and finding an earlier instance of the file in the list and bumping the date on that. Because of the shared nature of the CMS across different websites, we couldn't svn up in the CMS directory without destroying the current known state of the site. We also couldn't svn up outside of the subdirectory we were working on, as everyone else working on that site was working off the same network share. Everything was done very gingerly. The day one of the developers came up with a method to take a list of files from the spreadsheet, tar them up and FTP them to the server for later extraction, he was overjoyed and very, very proud. I got out of there, swore off PHP and its community entirely. I got tired of checking for a baseline of automated deployment, automated testing, version control, and individual dev systems at every single job I applied for; Ruby people don't look at you funny when you mention these things. Addendum: I personally know a developer currently working for a famous local radio brand who directly works on the live website network via an FTP plugin. He has to contend with other developers dumping the contents of archives directly into his public folder. (For context, this is all in Sydney, Australia.)

acdha 14y ago
FWIW, this is essentially how Oracle ships updates for their enterprise business systems: you get a tar file and a README telling you which files get copied to which spots on which servers.
dredmorbius 14y ago
If you can every track me down in real life, I'll buy you a misery beer.
- damncabbage 14y ago
  Haha, thanks. :-)
sauravc 14y ago
That shitty deployment experience has nothing to do with PHP. There are plenty of valid reasons to move to Python or Ruby, but better deployment stories aren't one of them. Objectivity seems to be in short supply here on HN.
- heretohelp 14y ago
  It has to do with community standards. The community standards for deployments and dependency management for Python & Ruby are much higher than PHP. virtualenv/rvm are the standard, using git is the standard, fabric/capistrano for pushing/provisioning is standard. This is not the case for PHP, the vast majority are using graphical FTP clients to manually overwrite files.
- AnswerAndForget 14y ago
  Isn't the ecosystem always trotted out while defending PHP, as well as its 'accessibility' to amateurs? Well, those amateurs are part of the PHP ecosystem, and you'll have to put up with that... or not.
- damncabbage 14y ago
  heretohelp made the point better than I did, but I explained my thoughts on that with this sentence: I got tired of checking for a baseline of automated deployment, automated testing, version control, and individual dev systems at every single job I applied for; Ruby people don't look at you funny when you mention these things. It's about expectations. I tried really hard to find a place that had all these in the PHP world. In the Ruby world (for example), it's a given. (I have only ever encountered one PHP shop during my rounds interviews that did automated testing... But they used CVS for version control. The very first Ruby shop I interviewed had all of the above, and treated it like they were no big issue.)