Continuous Deployment for Drupal 7 Tutorial for Developers | Agile web development in Washington DC

Working with a CMS such as WordPress or Drupal makes life easier for Web Developers, but once you want to start doing things the right way, a bunch of terms fall into your mind, such as: package managers, development environments, APIs, continuous integration, continuous development, etc. And you start wondering: how can I do this while working with a CMS?

Well, for sure you can, some of those will be easier than others, but you can. You’ll have to go deep and try things for yourself, read articles, follow tutorials and just do trial and error until you succeed.

This post is not about what Continuous Deployment means, so in a nutshell: Continuous Deployment automates the process of deploying code to any of the available development environments.

The main problem with a CMS like Drupal, is that a project can have a great percentage of “click programming”. Modules for Drupal like Features help exporting the configuration created by “clicks” into code that can be moved between environments. But if you have worked that way, you’d know is not an easy ride.

In this first part we’ll cover what concerns Drupal, then we’ll talk about tools to automate rest of the process.

Do everything in code!

If you have everything (or almost everything) in code you’ll be able to move painlessly between environments to avoid a lot of suffering (trust me on this).

Use case: You have to enable a module. In a regular scenario, you’ll add the code to your repository, and then you go to the admin pages to enable the module, right? Well, do it this way, instead:

$to_enable = ['some_module', 'another_module'];
module_enable($to_enable, TRUE);

I’ll show you how this can be useful.

Use the hook_update_N for Drupal

I won’t go into the details of the hook_update_N for Drupal, but you can if you want.

You can use that hook in a module and Drupal will run the code you wrote there when a database update occurs.

Following our use case:

function hook_update_70000(){
    //Enable two modules and its dependencies
    $to_enable = ['some_module', 'another_module'];
    module_enable($to_enable, TRUE);

    //Create a new content type called 'products'
    $name = 'products';
    
    //We don't want to create it more than once, right?
    if( in_array($name, node_type_get_names()) ) {
        continue();
    }

    $attributes = [
        'type' => $name,
        'name' => st('Products'),
        'base' => 'node_content',
        'description' => st('Some products.'),
        'custom' => 1,
        'modified' => 1,
        'locked' => 0,
    ];

    $content_type = node_type_set_defaults($attributes);
    node_type_save($content_type);
}

So, when you visit yourdomain.tld/update.php, two modules, and its dependencies, will be enabled, also a new content type will be created, without using the Drupal Admin interface.

Use Drush

With Drush you can control a Drupal site using the command line, so instead of visiting a URL to perform the database update you can, in a shell:

drush updatedb

Now, just running that line you will trigger the update, enable two modules and create a content type. Do you see now how easy it will be to move this to a new environment?

Ready to get your hands dirty? Let’s create some commands to automate the deployment to a develop environment (assuming we have a git branch called ‘develop’).

git pull origin develop
drush sql-dump --result-file='project-backup-`date +%F`.sql'
drush updatedb -y
drush cc all

First, we pull the code from the branch.
Create a database backup (just in case).
Run the database updates we created using the hook_update_N.
Clear the Drupal cache so we can see changes.

Important note: You’ll have to use the full path to your Drush installation.

Ok, so we learned how to avoid the Drupal admin interface and have everything in code (I’m sure you can research a bit more about how to do things programmatically in Drupal), in my upcoming Part 2 post I’ll talk about the tools we can use to automate the process, and how to use them. If you have any questions, feel free to leave a comment or contact us at inQbation if you need help with Drupal support.

Pro Tip: What if you create a module just to handle those updates? I personally use one and call it “deployment_manager”. Go ahead and use that name if you like it.

If you need someone to assist your business with continuos deployment for Drupal, we’re here and ready to give you a hand! Give us a call or drop us a message, anytime.

–