Upload
drupalindia
View
14.112
Download
3
Tags:
Embed Size (px)
DESCRIPTION
This is the presentation to be delivered on 31st jan '09 at drupal camp by Mukesh agarwal.
Citation preview
MigraineMaintaining Live Production Sites
Mukesh AgarwaliLoveBolly.com
AGENDA
Discuss the development methodologyDevelopment – Staging - Production
Synchronize our live websites with the current development
Migraine – Synchronize DatabasesSVN – Synchronize file system
What we need?
Add new features to the production site without affecting the content and of course with minimum downtime.
How does FACEBOOK or ORKUT or any other social networking site do it?? Do we ever notice these sites down for development?? NO!! Yet, there are so many new features so very often!!! That’s what we need to implement in Drupal!!!
Possibilities in Drupal
Unfortunately, there are not too many ways to proceed with migrating your development to the production.
Why is it difficult in Drupal?? Drupal stores a lot of its configuration in database, and there is no module or tool to draw a line between your configuration and content.
Disappointment for all those who thought it’s a 1-click feature
What then??
Don’t worry!! We are not in a no man’s land.
Big Shots might be using some rocket science, but then here comes MIGRAINE to aid of Drupal developers and make their life easy working with it.
Set the environment
Lets understand the generic 4-tiers here.Development
Working Environment for individuals or small teamsRadical changes can be tried without adversely affecting the rest of developmentOptional
IntegrationCommon Environment for developers to commit code changes – combine and validate work of entire teamSubset of data to test boundary conditionsRefresh/Update the subset frequently
Cont…
StagingTo test your new features with the existing contentSimulate as much of production environment as possible [including software configurations]Independent copy of production database to provide a true basis for QA testing
ProductionThe hosted website
SVN
Subversion (SVN) is a version control system, thus we can use commits and rollbacks.
Create a SVN repository at the development siteThe development team takes a checkout of this repositoryStaging can be at the same host as production [Pro: Identical server configuration for simulation]Staging is also a a checkout of the repository.
Points to note
Developers only commit only the changes that are tested on their local box.
Developers should work on different files. If they work on same file, then one commits, the other updates and then commit.
At no point is change made in staging or production environments.
Synchronize files
Drupal is very much extensible. We can customize our website completely without changing anything in the core. Make all your modules and themes available in sites/all dir
Now, we need to commit/update this and this directory only.
Developers commit from their local boxes when the change works fine for them.
Cont…
Integration site updates all these changes made by the developers and commits them if they work fine along with other changes made by the developers.
The staging site now looks for an update, checks the changes that are coming in, conforms with those made at the integration and then updates accordingly.
What with database?
Files are synchronized. Yes!! Not the database. We need to bring the configuration of integration environment to the staging and test it with the production content.
Let us now understand MIGRAINE
MIGRAINE
It is a python script that allows you to migrate content/configuration [acc to needs]
Drupal doesn’t have a strong concept of separation between configuration and content. The script attempts to provide one.
Freely available under the GNU General Public License
Requirements
Python 2.4 or higher – to run the python script
Shell Access – to integrate with your database
Most important, understanding of your drupal database – Its you who have to categorize your tables. Don’t worry you don’t need to categorize everything. [Tables for additional modules and custom content types need to be classified]
Migraine unveiled
So what’s the mystery behind the script? There are just 2 files that need to be manipulated
migraine.py – The python script that does all the work
migraine.ini – The configuration file given as an input to the python script
Test-Prod Analogy
Test site is the one which has the configuration required to migrate to production
Prod site is the one which has the content
Dev to staging – dev becomes test and staging prod
Staging to prod – staging becomes test and prod is prod
Settings file
Specifies the hosts ip/domain-name and the database name for test and prod servers
Also specifies the directories where the temporary database backups are stored
Optionally specifies the database prefixes – useful in case of multisite migration.
The python script
Defines six categoriesConfig – the configuration tables, e.g. variableContent – the content tables, e.g. node, usersTemp – temporary tables, e.g. watchdog, sessionsCache – cache tables, e.g. cache, cache_contentSequence – the sequence tableIgnore – tables that you don’t want to include
How to identify which tables go in which category?? Will look at it in the demonstration!!
Workflow
Takes a backup of test and prod databases before proceeding so that the databases can be restored if things do not work. The backup contains 7 sql files, one for each category except content which has 2 sql files, one for the content schema and the other for content data.
Compares the content schema of both databases using a diff command. Tricky!! Does not make any change if the schemas do not match and show the errors.
Cont…
Clears cache, dumps schema of temp tables.
If schemas match, replaces the configuration/content according to our need.
Also, updates the sequences table. [This is cool, as it updates rows according to the command we give]
Migraine commands
dump-test, dump-prod – take backup
migrate-to-test – migrate configuration from test to prod
migrate-to-prod – migrate content from prod to test
restore-prod, restore-test – restore databases in case of any complication
Demonstration
Lets go through the series of steps involved via a demonstration.
Few things – the demonstration assumes all the three dev-staging-production are on the same host, i.e. my localhost However, this works well with all of them being on different sites.
Limitations
Almost everything on earth comes with an exception, so does migraine.
Adding/removing/editing cck field definitions alters the content schema which is reported as an error and the script proceeds no further.
If there is an action that changes both the configuration and the content, there is no way to migrate it, e.g. Lightweight FeedAPI
Workarounds
CCK field definitions – Only workaround make same changes in dev and production.
Lightweight FeedAPI – bring content on dev/staging before migrating and simultaneously take the action on both places so that they are associated with the same content. Will also require to migrate and content of production to development at the end to avoid future conflicts.
Conclusion
Downtime is pretty low, optionally you can serve your site through another instance while migration is in the process.
Looking for a social networking site?? You will need to update features on regular basis to stay at par with your competitors!! Migraine provides answers to your ‘How … ??’ questions.
Thank YouFor the Patience
Happy Drupaling!!Do have a look at iLoveBolly.com