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.
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
