I'm slowly going to be running a series of posts on running Concrete5 through multiple environments. There are many challenges to running a CMS in shops with strict development practices.
One of the challenges that immediately comes to mind is the ultimate need to create a release flow that affords you a stable production instance.
Smaller organizations tend to be limited on resources or talent and find themselves developing on the production server.
Most medium to large organizations soon desire to have more transparency in the development environment. They want to weigh in on technology and implementation decisions and ensure that stable products are released.
One of the first things you can do to improve your development environment is to create a multi-staged environment. Creating a good mutli-staged environment affords you a place to develop, a place to iterate and finally a place to serve production code. This generally involves providing an interface for changing settings between environments.
I'm going to show how you create a multi-staged environment using Apache and Concrete5's config/site.php file.
The first thing you need to do is edit your Apache virtual hosts directive for your Concrete5 website and establish an environment variable that we can use to switch between environments. My virtual hosts directive is located in a file in /etc/apache2/sites-available.
ServerName www.mysite.com
DocumentRoot /var/www/mysite
SetEnv C5_ENV production
Note the SetEnv line. This is the bit that will change between each of your environments. On your dev server, set it to 'development', if you have a staging server, set it to 'staging'. Use a simple single word that best describes the environment. In my own environment I have:
- development (runs on my own machine, used for active development)
- stage (runs on a server, used for displaying code)
- qa (runs on a server, used as a testing ground for the Quality Assurance department)
- production (runs on a server, stable production code)
My typical workflow involves lots of changes in development, occassional iterations on stage, few deployments to qa and finally very few deployments to production. Basically production is only for tested code that you consider to be stable.
The next step is to modify your config/site.php file to treat each environment differently. Here is what my file looks like:
define('DIR_REL', '');
define('PASSWORD_SALT', 'hahayeahright');
setC5Environment();
switch(C5_ENV) {
case 'development':
define('DB_SERVER', 'localhost');
define('DB_USERNAME', 'dev');
define('DB_PASSWORD', 'dev');
define('DB_DATABASE', 'c5_dev');
define('BASE_URL', 'http://mydevurl.com');
break;
case 'qa':
define('DB_SERVER', 'myqadbserver.com');
define('DB_USERNAME', 'qa');
define('DB_PASSWORD', 'qa');
define('DB_DATABASE', 'c5_qa');
define('BASE_URL', 'https://myqaurl.com');
break;
case 'production':
define('DB_SERVER', 'myproductiondbserver.com');
define('DB_USERNAME', 'prod');
define('DB_PASSWORD', 'supersecretpassword');
define('DB_DATABASE', 'c5_production');
define('BASE_URL', 'https://myproductionurl.com');
break;
}
function setC5Environment() {
$c5_environment = (strlen(getenv('C5_ENV')) > 0 ? getenv('C5_ENV') : 'development');
define('C5_ENV', $c5_environment);
}
?>
There are a few notable things here. First is the introduction and calling of the setC5Environment() function which ensures that you have a default environment to run in if all else fails. The next is the switch statement that changes which settings you prefer to use in each environment. Lastly of note is that the C5_ENV constant will be accessible throughout your site, meaning that you can key off of this in any number of ways.
Using this menthod you can safely operate in multiple environments without modifying your configuration with each deployment.
Subscribe
Please add a comment
One question, it seems like concrete does not know what to do with the sitemap. Any way around this?
I'm worried there are other site specific info or settings stored on the filesystem...
It will most certainly be an issue. Part of your deployment strategy should involve running the scheduled tasks to regenerate this file.
In my experience, I don't carry over sitemap.xml or the files/cache directory when I deploy.
Some of my follow up articles will actually encompass simple workarounds to avoid this.
Come on, people, this sort of stuff can't be "all live, all the time!" (SharePoint, I'M LOOKING AT YOU.)
I hope C5 does this better. I'm eager to see where this goes.
Leave a Reply