Ideal Testing and Deployment Workflow
Permalink
Hi everyone,
My company is shifting to C5 for our new clients, and I'm trying to find the ideal workflow to reduce the possibility of mistakes being made. Multiple content editors and developers work on each site, and all changes must be approved by our proofing department before going live.
So currently, we have a testing server and a live server where the sites are deployed. Our current system is that content changes are made on the live server, but they are only previewed. Once they're approved, the changes are published. Template changes however, must be made on the testing server and are uploaded when approved (they may also be made on developer's local machines before being committed to the test server).
The problem there is that the testing installation must have a different configuration file than the deployed installation, and I'm worried that it's far too easy to mistakenly overwrite this file during a deployment and botch a client's live site.
So I'm trying to get an idea of how other users handle this situation. Keep in mind that multiple people work on these sites and we have clients to answer to, so a foolproof system is necessary.
Thanks in advance,
Alex
My company is shifting to C5 for our new clients, and I'm trying to find the ideal workflow to reduce the possibility of mistakes being made. Multiple content editors and developers work on each site, and all changes must be approved by our proofing department before going live.
So currently, we have a testing server and a live server where the sites are deployed. Our current system is that content changes are made on the live server, but they are only previewed. Once they're approved, the changes are published. Template changes however, must be made on the testing server and are uploaded when approved (they may also be made on developer's local machines before being committed to the test server).
The problem there is that the testing installation must have a different configuration file than the deployed installation, and I'm worried that it's far too easy to mistakenly overwrite this file during a deployment and botch a client's live site.
So I'm trying to get an idea of how other users handle this situation. Keep in mind that multiple people work on these sites and we have clients to answer to, so a foolproof system is necessary.
Thanks in advance,
Alex
We usually enclose the server specific settings in a switch statement, then the site.php file loads the correct info based on the $_SERVER server name variable, with the live as default. Keep the password salt the same for all servers so the db can be shared. And for db schema changes use config/site_db.xml
Thanks for the tip. I edited the BASE_URL and DIR_REL constants as follows, and so far it seems to work perfectly.
define('BASE_URL', 'http://' . $_SERVER['SERVER_NAME']);
define('DIR_REL', str_replace('/index.php', '', $_SERVER['PHP_SELF']));
define('BASE_URL', 'http://' . $_SERVER['SERVER_NAME']);
define('DIR_REL', str_replace('/index.php', '', $_SERVER['PHP_SELF']));
All that "<a href" gobbledygook isn't supposed to be there. How do I tell the post editor not to auto-replace perceived links like that?
Well fixed it sorta just be removing the code block. Any chance we could the C5 site administrators to fix the "Post Reply" form so it doesn't auto-replace suspected links when they're within a code block?
This seems like a cool way to go. Being a Flash developer, I'm a huge fan of making the same file work during testing and during deployment. Since I need Flash projects to work locally and when I post them to the internet, I usually check the sandbox type and provide different content paths depending on where it's running.
I'll have to try applying this trick to some of my Concrete5 projects. It would be great to make the move from a development server to a live server this much easier.
I'm guessing that the .htaccess files will still need to be unique, though, unless they both are installed to the same directory on each server? I guess that's ideal anyway, since links in Content blocks get off otherwise.
I'll have to try applying this trick to some of my Concrete5 projects. It would be great to make the move from a development server to a live server this much easier.
I'm guessing that the .htaccess files will still need to be unique, though, unless they both are installed to the same directory on each server? I guess that's ideal anyway, since links in Content blocks get off otherwise.
In most version control systems you can setup a ignore rules.
For concrete installs I do:
cp config/site.php config.site.php-default
Ignore:
files/cache_objects/*
files/cache/*
config/site.php
I wrote up a guide to this process using Bazaar at
http://track.toomanytabs.com/bzr_for_webdev...
For concrete installs I do:
cp config/site.php config.site.php-default
Ignore:
files/cache_objects/*
files/cache/*
config/site.php
I wrote up a guide to this process using Bazaar at
http://track.toomanytabs.com/bzr_for_webdev...
Yeah, that's what I've been doing, using Mercurial, but even though it's a simple file that rarely changes, I'd rather have it in the repository. Makes clones easier and makes me feel a little better inside.
"but even though it's a simple file that rarely changes, I'd rather have it in the repository" okalex
If you duplicate config.php to config.php-default you still keep the file in the repository...
The other reason to ignore and provide a default version is security. Running the same username and password on local, dev/staging and live is a minor risk. A simple ignore removes this risk.
If you duplicate config.php to config.php-default you still keep the file in the repository...
The other reason to ignore and provide a default version is security. Running the same username and password on local, dev/staging and live is a minor risk. A simple ignore removes this risk.
I'm using a virtual appliance.
You can search for jumpbox or vmware virtual appliance in your fav. search engine.
1. upload the concrete5.zip from sf.net
1.1 prepare the database
1.2. unpack and install it.
2. edit content and code here/there on the virtual machine using scp.
2.1 hit the backup button to backup db+files into one zip.
3. secure my online server up with a password.
3.1 upload the zip to the internet on my server
3.2 upload my unpack script.
3.3 execute the unpack script and remove it afterwards
3.4 insert my database dump into the online server
4. Done ;)
Of course database name and password are the same on the vmware as on the online server.
You can search for jumpbox or vmware virtual appliance in your fav. search engine.
1. upload the concrete5.zip from sf.net
1.1 prepare the database
1.2. unpack and install it.
2. edit content and code here/there on the virtual machine using scp.
2.1 hit the backup button to backup db+files into one zip.
3. secure my online server up with a password.
3.1 upload the zip to the internet on my server
3.2 upload my unpack script.
3.3 execute the unpack script and remove it afterwards
3.4 insert my database dump into the online server
4. Done ;)
Of course database name and password are the same on the vmware as on the online server.
