One of our long-running projects follows an approach of releasing several new features together. This means that hundreds of features get developed and tested, but do not get deployed for many months. Since there are movements of developers across projects, tracking the features and how they have been developed prove challenging, especially when it comes to deployment.
So recently, when the time for deployment came, our team was in a fix. We tried to do a manual deployment, but it proved to be extremely time consuming.
The second way of deployment was to handle it through the Features module of Drupal. When we tried that, we realized that we needed to code some more in order to deploy it. And even after that, many of the new features were not being reflected. So not only was it time consuming to deploy it through Features, it was also not really able to deploy the features properly.
That’s when we thought of doing a structural-level migration of information from one database to another. This is not the usual method for a deployment, but with many features to be deployed, this seemed like a good way to take.
And we were right. We looked for the places where the information resided and moved blocks of those to enable the deployment. Here’s what we did.
We collected the name of schemas/tables holding the information about view, block, panel, rule, content type, permissions, etc. Our strategy was to only carry the information in those tables which had structural data populated in them. We identified the number of tables with this information.
STRUCTURAL DUMP
FileName: structure.sql
views_display, views_view, block,
block_custom, block_role, blockcache_alter,
panels_display, panels_pane, custom_breadcrumbs_panels,
page_manager_handlers, page_manager_pages,
context, facebook_rules_user_tokens, rules_config,
rules_dependencies, rules_tags, rules_trigger,
facetapi, quicktabs, menu_router,
menu_links, i18n_string, role_permission,
locales_target, locales_source, image_effects,
image_styles
Since there were many content type level changes, we compiled the information from variable tables and exported them. If you are going to try this, please take care that you bring all the settings in the Dev Server and compare it from the variable table on the live server.
VARIABLE DUMP
Filename: variable.sql
SELECT * FROM variable WHERE (name like '%academy%' or name like '%opportunity_follow%' or
name like '%apps_type%' or name like '%ask_question%' or name like '%campaign%' or
name like '%club_rank%' or name like '%competition%' or name like '%competition_group%' or
name like '%competition_winner%' or name like '%group_invites%' or name like '%project%' or
name like '%report_abuse%' or name like '%volunteering_hours%' or name like '%volunteering_rank%' or
name like '%htmlmail_postfilter%' or name like '%mail_system%' or name like '%htmlmail%' or
name like '%ant_pattern_%' or name like '%privatemsg%' or name like '%print_pdf_%' or
name like '%rules_forms_event_info%' or name like '%vh_state_%' or name like '%r4032login_%' or
name like '%date_format_%') and name not like '%solr%'
Note: We replaced INSERT INTO with REPLACE INTO to do a forceful entry.
Here are the steps for the deployment on the live server from the staging server.
1. Take the live Site into the offline mode.
Admin Path: en/admin/config/development/maintenance
2. Take the live server database backup
3. Deploy a tag on the live server from the staging server.
4. Export the content types from the staging server and import it to the live server.
5. Enable the required modules on the liver server.
6. Apply the structural changes to the live server.
drush sqlc < structure.sql
7. Apply the variable level settings changes to the live server.
drush sqlc < variable.sql
8. Run the updates on the live server.
drush updb
9. Clear the cache from the live site.
drush cc all
10. Take the site off from the maintenance mode.
The deployment is done! It took us just 20 minutes to complete all these steps and make the go live.