Linux Website Deployment Strategy

May 20, 13 by kenrich

Recently, I put together a set of steps for deploying new code to our Linux websites.  Below is a list of all of the steps we take to deploy new code.  Note that this is a work in progress and is still being improved and expanded upon with each deployment.

Feel free to adopt any of these strategies for your own business.  It is always best to do deployments after the peak hours which is around midnight on the West Coast.  You should also try to keep your maintenance periods as short as possible.   Performing a dry run before the actual deployment should help you meet this goal.

Put the site into maintenance mode

Uncomment the code in the .htaccess file at the website root

# Uncomment the following to enable maintenance mode
# RewriteCond %{REMOTE_ADDR} !=127\.0\.0\.([0-9]|1[0-9])
# RewriteRule ^maintenance.html$ http://%{HTTP_HOST}/ [R,L]

Make sure to substitute your IP address in the RewriteCond so that the developers still have unrestricted access to the site for deployment and testing. You can retrieve your local IP from my former site: http://www.whatip.com/

Test that maintenance mode is activated successfully

We need to access the website from a different IP address.  See Ensure the Site is Really Live below for instructions on how to do so.

Upload the Latest Sync Code (if necessary)

If we have made updates to the synchronization code, upload this first to make sure that everything goes well.

If any database schema or data changes need to be made to support the synchronization process, make these changes manually before proceeding.

Perform the Database Schema Sync

Initiate this on the development (or staging) machine.  Analyzes differences between the local database and the production.  Prompts the user to deploy changes to production that will modify the schema and bring it into sync with local.

Perform the Database Data Sync

Much like the schema sync, the data sync will look for database records on the local machine that are out-of-sync with the production server.  It will then prompt the user to deploy these changes to production.  The user will have the ability to confirm or reject changes selectively.

Perform the Code Sync

Next we need to perform the code synchronization.  This includes server-side scripts, javascripts, resources (images, videos and .htaccess files).  An automated script will analyze and present the user with all change detected.  At this point the administrator may approve or reject changes and deploy them to production.

Smoke Test the Application

Now that all of the code and database modifications have been made, we need to verify that the site is working properly.  Since the site is available for us (due to the RewriteCond we placed in our .htaccess), we can run our tests on the live site.

 

Some tests should not be run on the live server such as those which make database changes that cannot be easily undone.  These should be done on a staging server instead.  Smoke testing usually involves a human tester going through most of the features of the site to check that they look okay.

Take the Site Out of Maintenance Mode

Comment the code in the .htaccess file at the website root so it looks like the following:

# Uncomment the following to enable maintenance mode
# RewriteCond %{REMOTE_ADDR} !=127\.0\.0\.([0-9]|1[0-9])
# RewriteRule ^maintenance.html$ http://%{HTTP_HOST}/ [R,L]

Ensure the Site is Really Live

Load your web site using a different IP than the one you excluded in your RewriteCond.  There are websites available to do this.  One of them is http://www.webpagetest.org/.

This entry no have comments... but you can be first.

Leave a Reply

You must be logged in to post a comment.