From: Bill Stephenson
>
> On Sep 12, 2012, at 9:18 AM, Mark Haney wrote:
> > My question is, what IS standard practice for this?
>
>
> I use a few different methods. One is to make the changes on the dev box,
> then use BBEdit to "Compare" that to the file used on the live server. BBEdit
> allows me to copy just the lines of code I want to the live file and save it.
>
> If I have reason to worry that using FTP to save a file might corrupt a users
> experience with the app then I make a copy of the changed file with a new
> name and upload it to the live server and "rename" it the same as the live
> file. I I'm doing this often I make a script and run it on the server:
>
> rename("../myCode.pl-new","../myCode.pi") or die("Error 2: $!");
>
> Now, from what I understand, and I am sure others here will correct me if I
> am wrong, this makes the change on the "Atomic level" and it will not
> interrupt your app.
Just for fun, let me describe our process, which is at the other end of the
spectrum. Some of our web servers handle credit card transactions, so must
conform to PCI requirements and pass a monthly audit. As a result, many of
these procedures are dictated by those requirements. Also, these procedures are
basically the same for all languages and applications.
All of our code, including test scripts for Selenium and SQL for database
schemas, is managed by Perforce. When I need to make changes, I first get a
copy of the code from Perforce, and manually set up the new build directories
on a server VM in our ESX farm. As I make changes, I only check out the files I
actually need to edit. Once I have finished my changes, passed all of my
Selenium test suite and any other tests I believe are necessary, I check the
changed files and any new test scripts into Perforce.
When the Hudson server notices those updates in Perforce, it does a master
build, creating an RPM for a new install and one to update an existing site. It
then installs those files on its test server VM and runs through a number of
automated tests using Selenium. I am notified of the results via email with
details available on the Hudson web server.
After the build passes the automated tests, QA uses the build server to
generate similar RPM modules for their server VM and installs them. They then
go through a number of functional, integration and fuzz tests on that server.
When those are completed, they release the build to Production. (Since many of
our sites are PCI certified, neither Development nor QA have access to the
production servers.)
Production then generates their own RPM modules and schedules the updates to be
deployed, both to a client preview server and to the production servers. Each
client may then review the former and decide if or when to switch their virtual
domain over to the new build on the production site, which we host for them.
Every released build is available on each server, and each client has control
over which build they prefer.
As somebody else mentioned, we go to great lengths to insure that each server
VM is identical to every other in the chain. Each test server is as near a
clone of the production server as we can make it. This not only makes the
automation possible, but it simplifies the build process as well.
Bob McConnell
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
