Drupal Website Deployment - Staging --> Production

Working with a Drupal development team on a large website that was continually being updated by the client sets some very challenging issues. You'll know the hassle when it comes the time your client wants to start adding more new features or sections to their existing site. The question you'll begin to ask yourself is
"How do we add the new features while the client continues to update their site without losing the updated contents when the new features have been completed?"
This is a complicated matter and there is no easy solution whether you use CVS, Subversion (SVN) or none at all. As useful as they are, these Version Control applications only keep tracks of file changes and not the database. Drupal stores almost everything in the database.
There are a few very tempting quick and hassle-free solutions but i would certainly avoid them:
- Work on a development site and add the features then transfer the changes over to live site losing all newly added content. Tell your client they'll have to redo all the content they have created prior to the site transfer. Sure your client will be happy.
- We could make a backup and work on the live site and let the client know when the work will be carried out and completed. Not a good solution as you will be causing a lot of disruption on the daily running of the site and what if the changes take longer than a day to complete?
- What if the changes screwed up the live site? sure you have a backup but isn't this going to reflect badly on your client if their visitors see all the error messages or they cannot access the site due to a bug.
The way we tackled this as a team was to create the additional features on a development site and document the whole process. Then, on live site go through the procedure of applying the changes from documentation. Depending on the changes made, some times it had to be implemented in stages and at times we had to choose a time of the day when traffic to client's site is low. As you can see, this is not productive at all and again may lead to some unforeseen issues.
Only recently, i came across an article by Developmentseed that deals with this very same problem that many web shops faces. But they have a good solution and the wonderful developers over at Developmentseed published a practical article. You really must check it out to avoid the same pitfalls.






Comments
Would you believe the size of
In the Apache world, you might be familiar with tweaking your config file(s) and then running $ apachectl configtest to see if the config parses. We've been discussing this on the drizzle mailing list and talking in general about configuration handling and management. Well, it turns out that you can fake it in MySQL and Drizzle too. If you have a new configuration in /tmp/new.cnf, try this: $ mysqld --defaults-file=/tmp/new.cnf --verbose --help And it'll run mysqld (or drizzled), parse the...
Add new comment