deployment strategies, PHP + SVN

Question

i just wanna discuss our deployment strategy and find discrepancies in it. the process goes like this

-> Development finishes for a particular release

-> All developers commit their files to trunk

-> Compare database schemas using TOAD and migrate the changes

-> Create a new branch on SVN

-> Export using SVN (to remove .svn folder,etc)

-> minify the JS, CSS

-> upload to staging server

-> perform test cycle

-> fix bugs on the branch and verify them

-> re-minify the JS, CSS [if required]

-> upload to production server

-> when i say upload, it means uploading files through SSH to /var/www/html folder

-> first upload js, css, images

-> then upload php files

-> during upload exclude directories like user uploaded pictures, etc.

-> perform test cycle

-> fix bugs and upload again (may need re-minify - few files)

-> verify bugs

-> verification completes

-> commit branch to svn

-> merge changes back to the trunk

-> commit trunk [during this deployment cycle, no one commits any files to the trunk]

the process is really complicated and requires lots of attention.

any suggestions on how we can improve it?

Have the developers commit at least daily. Use a Schema Manager to automigrate the DB changes and version them in your VCS. Use a Continuous Integration server and a build tool like Phing. Have a look around SO. These topics have been discussed before. — Gordon

Tor Tor · Accepted Answer · 2010-11-24T19:51:37

I used the following deployment path. It removes many of your needs to re-upload files to different directories. After initial setup, the most complicated work you will have to do is "svn update" commands in each of your test locations.

This setup assumes you use config files for pointing to directories like assets, images, and css.

Init repository. Always have a unique user for production and test checkouts. This allows for unique commits from live server back to trunk in emergencies.
Devs develop and commit. Builds are tagged with build number, as well as a tag for LIVE when they are supposed to be project ready.
Checkout is made on test server. If everything goes swell. #dev.example.com/~test/project/
svn update to a test directory on production server. #example.com/~test/project
svn update to your main project directory on production server to LIVE tag. #example.com
If you have any exceptions in steps 3 through 5, return to step 2.

All projects have a config file, that allows one to set paths to development databases, shared images, etc. config.dist.php works well as a naming schema. Each checkout then copies config.dist.php to config.php. This allows for many configs without SVN collisions.

Each config file typically has some code such as

<?php
    #hopefully, your project can leave these first two constants set to '', because relative paths work for everything
         define('localPath', '/home/www/projectName');
         define('baseURL', 'http://example.com/~projectName');

    #if you want to write everything over a shared filesystem for instance, uploads.
         define('localAssetsDirectory', '/sharedFileSystem/localPath');

    #if you want to include a shared assets directory
         define('assetsURL', 'assets/images');

    #OR if you want to host assets in one location.
         define('assetsURL', 'http://assets.example.com/images/'    
 ?>

All test versions on production and dev server are only accessable by restricted ips, as well as put behind a .htaccess file. Apache is configured to not serve .svn directories.

deployment strategies, PHP + SVN

2 Answers