NYCPHP Meetup

[Paul A Houle]

Anthony Papillion wrote:
>
> So I’m a bit curious and perhaps I’m missing the point here (probably 
> am) but why go through all this hassle? Why not just do a straight FTP 
> of the files from the staging machine to the deployment machine? Does 
> using checkin/check out benefit us in some way besides the original 
> file integrity and management?
>
> Anthony Papillion
>
Well, FTP has the advantage of inertia. In a lot of IT departments, FTP 
is still considered a viable internet protocol, despite numerous 
problems: (i) it's over-complicated nature means that FTP clients and 
servers tend to be full of security flaws and (ii) it's just not 
compatible with the way the internet has worked ever since 1995 or so 
(NAT, Firewalls, etc.)

The inventors of 'SFTP' pulled a brilliant marketing coup by 
incorporated the three letters 'FTP' into the name of a modern protocol 
that has no relationship whatsoever with FTP.

Now, I'm assuming here that we're working in PHP so that there isn't any 
compilation, need to kick the server to unload Java classes, etc. 
Deployment issues become more complex as you have more artifacts like 
that. There's also the issue of how you deploy changes to database 
schemas and content.

If a system is busy, for one thing, I'd be concerned that many FTP-based 
ways of maintaining the state of a system would leave the files in an 
inconsistent state for several seconds to several minutes. There might 
be some some software out there that's smarter, but the obvious thing to 
do that "always works" is to delete the target directory and re-copy it, 
which means the system will be unnecessarily busted for some time. Rsync 
does better, but in my experience git, particularly with a local 
repository, is incredibly fast.

The big advantage for having your production system be 'checked in' is 
that you can make emergency changes directly to the production system, 
and then check them back into source control.

You certainly don't want to make changes in your production system on a 
daily basis, but I've faced situations, particularly when dealing with 
abusive user behavior, a wonky OS on the production machine, or bad 
interactions with external automated systems, where a very small patch 
to the production system (carefully monitored) is the most effective way 
to solve a problem. If your production system is checked in, you can 
manage this sort of change very easily -- you can keep track of what was 
done, when and be able to check it in or back the change out.

I've got a pretty nice system for website deployment on the server that 
serves up

http://ny-pictures.com/

that server isn't heavily loaded yet, so I often run development, 
staging and production environments on the same system. I can deploy new 
instances of my 'CMS' in less than a minute. The only real trouble I've 
got is that I've got some databases that take 30 minutes to mysqldump 
these days... Also I am starting to have a number of things that are 
"compiled" in my system such as metadata that controls the autoloader, 
the data dictionary, and, soon, a cache of commonly autoloaded classes 
that will improve the effectiveness of an opcode cache.

Now, if you're working in a clustered environment, where there are 
multiple copies of the software pushed out to multiple servers, that's a 
whole different game.