After much trial and error I've developed a workflow that allows me to quickly and efficiently setup sandbox environments as needed in a matter of minutes. A 'sandbox' and can be used for 'staging' of Magento development (dev -> test -> production) and involves a combination of database backups, scm (e.g. git), shell scripts, subdomains and localhosting.
In addition to using these techniques for a staging workflow for development, these techniques can be extended to provide a way of working with 3rd parties (contractors or extension publishers) in a secure / scrubbed environment that firewalls them from production environment and data.
There is a lot of detail here, but once this is setup it is a very productive workflow for developing and testing your Magento install in isolated sandbox(es).
Setup New Sandbox
To setup a new 'sandbox' for my Magento installation from an existing product site, take the following steps.
It isn't uncommon to have multiple sandboxes, one might be a subdomain dev.mydomain.com (on same host) and another might be a localhost domain localhost.mydomain.com (using hosts file to map the domain)
- Setup a new hosting environment for sandbox
- can be a subdomain, or localhost of my magento site
- including new hosted domain, perhaps use a subdomain of my site on the same hosted server, or something local
- create a new database (with different name and credentials to avoid unfortunate accidents)
- 'clone' the site repository into the sandbox environment
- create (or use existing) branch for the sandbox 'role' (e.g. test or dev)
- perhaps separate branch for production and use 'master' as an integration branch
- edit the localhost.xml, not in scm to keep it environment specific
- using the new database and different credentials to be safe!
Once you have an established sandbox environment you can repeat the following steps each time you want to refresh the sandbox with the latest production version.
Refresh Sandbox
The following steps can be done manually, or automated with shell scripts.
Refresh the source from the scm
- Something like 'git pull' and 'git checkout devbranch' for your preferred scm and branch
Load the latest production database backup into the sandbox database server
- Typically using 'mysql' command line
'Localize' the database to the sandbox environment very important
- Without localizing your database to your sandbox environment many unexpected behaviors can occur. For example, existing cookies in your browser could affect the behavior of your sandbox environment if you don't have some uniqueness to the cookies for your sandbox.
The following is an excerpt from a shell script that localizes the database to the 'sandbox' domain. These steps can be normalized or you can define the shell variables in your own shell script and for the command-line database tool appropriate for your environment.
echo -e "* Step 1: change site URLs from production domain to staging domain"
$DBCALL -e "UPDATE core_config_data SET value = REPLACE(value, 'http://$OLDDOMAIN', 'http://$NEWDOMAIN') WHERE value like 'http://$OLDDOMAIN%'"
$DBCALL -e "UPDATE core_config_data SET value = REPLACE(value,'https://$OLDDOMAIN', 'http://$NEWDOMAIN') WHERE value like https://$OLDDOMAIN'"
echo -e "* Step 2: Replace all production notification email addresses with a test email address"
$DBCALL -e "UPDATE core_config_data SET value = 'test@$ROOTDOMAIN' WHERE value like '%@$ROOTDOMAIN'"
echo -e "* Step 3: VERY IMPORTANT! Update cookie domain to avoid cookie collision with live site"
$DBCALL -e "UPDATE core_config_data SET value='$NEWDOMAIN' WHERE path='web/cookie/cookie_domain'"
Anonymize the database
- This is a critical step if you want to allow 3rd parties access to a dev / testing environment.
- This shell script can be customized to your own needs
Delete the contents of the var/cache directory
Ready for Development!
You are now ready for development in your sandbox. This might involve multiple commits to your scm branch, staging from dev to test (following similar techniques) and
Complete development and testing
- optional testing in a separate staging environment.
- one approach is localhost for development, and a subdomain on the production hosting environment before bring your changes into to the live enviornment.
Commit and push your changes to your
Staging your changes to production
After you have completed development and testing, time to move your changes to production.
Merge your changes into your production branch
- Use your preferred workflow, one approach is to merge all dev changes to a master branch and from their to live or production
Pull/Checkout your changes into your live site
- Bring your changes (now in your live branch) from your scm
- clear your cache
Done!
With this workflow, and some shell automation, it is possible to refresh a sandbox environment from production environment and data to a sandbox, develop/test changes, and deploy safely back to production in a matter of minutes.