Automating, Building, Testing and Deploying to Production Server

[Paul Rubin]

"yoda" <nochiel at gmail.com> writes:
> I realize I'm losing so much time I could spend more productively. I'd
> therefore like to know the different approaches you guys employ to
> deploy builds from your staging servers (or laptops:) to the production
> server in an automated repeatable safe manner.

This is really a wide-ranging question and clpy maybe is not the best
place for it.  Basically every installation does it differently
depending on its requirements.  You could google some phrases like
"continuous integration" and "configuration management" to see some
approaches.  The general outline is:

1) QA dept. has a server configured as identically as possible to the
   production server.

2) Engineering releases a sw version by making a source control
   branch.  QA checks out the branch and tests it against pre-agreed
   release criteria.  If there's differences of opinion about criteria,
   QA manager and engineering manager meet to resolve differences.

3) when QA manager and engineering manager agree to release, code is
   pushed out to production server (same process as release to QA:
   someone logs onto the production server and does an svn update or
   whatever).  How that's done depends on how the server works.  I
   worked at one serious web site which worked as follows.  We had a
   primary server and hot backup (secondary) server, so we did pushes
   by taking the backup server offline, checking out the new build on
   the backup server and running some sanity tests, then launching the
   service on the backup server and taking down the primary, so there
   would be an automatic failover to the backup which was now running
   the new code.  We'd then upgrade the primary the same way, and fail
   over again if desired.  Smaller sites with no hot secondary will
   typically go briefly offline for version upgrade.  Larger sites
   with multiple primaries could have a more gradual process where
   primaries are upgraded one by one, or whatever.

4) Some high availability services (e.g. telecom) need hot upgrade
   (code replacement without stopping the application or interrupting
   connections).  This needs to be built into the app architecture at
   a deep level and I don't think it's what you were asking, but some
   languages like Erlang make provisions for it.

Generally, a release cycle for an online service isn't that much
different than that for a shrink-wrapped software package.