Drupal Deployment Strategy
Like many frameworks, with the use of version control deploying code in Drupal is easy but deploying database changes is difficult unless we follow some proper deployment techniques. If we follow proper deployment strategy, we can lead hassle free life while moving changes from one environment to other.
If we don't follow any deployment strategy, After every code push to stage or production or any other environment, we have to login as admin or some other authorized role user to the website and update the necessary database changes manually. Here the risk is that we may forgot some of the changes or misconfiguration which lead to serious deployment errors and have to spend sleepless nights.
Below are my suggestions for setting up good deployment strategy to avoid manual updates in site after code deployment.
Install features and some of its useful addon modules.
Features: Using features module, we can export all drupal database configurations like content types, views, panel pages, fields, taxonomies, user account settings, comments , user permissions etc., as modules and maintain those changes in version control.
Strongarm - Used to export most of the settings which are stored in variables table
Features extra - Used to export block settings
With above three modules, we could be able to export most of the configurations into and easily maintain in version control.
Custom Deploy module
If we miss any change(s) which are not possible to export using features module, still we have to move those changes into code to maintain in version control using hook_update_n scripts which should be written in a file of any module.
To maintain proper deployment strategy, we have to write one custom module with like <your_app_name>_deploy and inside <your_app_name>_deploy.install file all your updates in hook_update_n scripts.
About HOOK_UPDATE_N
Implementations of hook_update_N() as <module name>_update_<number>. The numbers are composed of three parts:
1st part is single digit which is for Drupal core compatibility (e.g 7 for D7 OR 8 for D8).
2nd part is single digit which is for your module's major release version (e.g., 1 for 7.x-1.* or 2 for 7.x-2.* series of your module). This digit should be 0 for initial porting of your module to a new Drupal core API i.e from D6 to D7 upgrade.
3rd part is two digits which for sequential counting, starting with 00.
When you run <your_app_url>/update.php in , your latest update hook will be executed based on the update number. In system table under schema_version column, the last update number will be stored, so next time when you run update.php, it will check the last schema_version and if it found new update number(s) which is greater than last update number, it will execute those changes.
Ex:
<your_app_name>_deploy_update_7100(&$sandboc) {
module_enable(array('module_1', 'module_2'));
}
After run update.php successfully, it will enable the module_1, module_2 and in system table 7100 will be stored in schema_version column for the specific module here it is <your_app_name>_module.
Next time if we run the update., the system will check the hook_update_n scripts from all modules .install file, For our deploy module, if it finds any hook_update_n script(s) which is greater than 7100 (which is already executed), it will execute it.
By following above deployment strategy, we could be able to deploy all drupal database configurations very easily across multiple environments lead hassle free life.
