When I built my first Drupal site, I was really excited about how easy it was to just download modules, click through a bunch of pages to get everything functioning just the way I wanted it, then transfer everything to my server and have a live site for which I didn't have to write a line of code. Incredible, right? Well, then I launched the site and realized I wanted to make some changes. So, just log into the site and change things around? Well, this seems like a good idea until you go to update a module one day and the next page you click on gives you a white screen of death and you're site is broken. Quick! Panic! So eventually you figure out what happened, get your site running again, and then the next time you want to make a change, you have learned from your experience and think "OK, there's got to be a better way to do this." So, this article will lay out my thoughts and methods for dealing with this problem; the specific challenges of dealing with deployment in Drupal; and a list of tools needed to go from Drupal enthusiast to professional team developer.

A quick definition

If this is the first time you're thinking about a deployment process for a project, let me just describe the problem and the goal in a little more detail. When you first start developing a site, you're generally working in a local development environment (probably involving an acronym ending in AMP, and if you're not that far yet, check out the Acquia Dev Desktop as a great way to get started). You then transfer your files and your database to your web server where the site can be used, but probably want to keep developing new features. As in the scenario described above, you want to keep developing on your local machine.

Inevitably on larger projects, you will be collaborating with more than one developer: maybe someone doing configuration, someone else doing theming, and perhaps a third person working on some custom modules. So now you have three development environments and a live site. How do you co-ordinate all of those changes? It's hard. You then need another server somewhere to put up all of your changes together and test before you put them on the live site, and things get complicated quickly.

Dealing with all of this is called deployment. i.e., How do you get new changes onto a live site without crashing your site.

So why is this hard, anyway?

We'll talk about tools in a moment, but the first thing to recognize is that our biggest problem comes from all of the configuration stored in the database. Every time you enable a module, change some settings, write an article, configure a block, or do just about anything else on your site, those settings get stored in Drupal's database. At the same time, changes are happening to the database on your live site as new articles are created, people comment, new users sign up, etc.. There is no easy way to merge two databases together. In fact, it's really difficult and has been the subject of great debate in the Drupal Community, has spawned some incredible tools for dealing with this, and is in fact one of the 5 major initiatives for Drupal 8.

Stocking Your Toolbox

You can fix a lot of things on a car with some wrenches and a screwdriver. If you've spent much time working on a car though, then you've quickly realized that to go further than changing fluids or replacing a battery, you're going to need some specialized tools. I won't be focusing in great detail about any of these, but each one of the tools listed below links to an article that will be a good starting point for learning about the tool in more detail. As a side note, if you're just getting started thinking about this, beware that this can be a little daunting at first. Hang in there though, these tools and proper use of them will save you a lot of time and pain in the future.

Version control, or: got git?

Version control is software that tracks all of the changes you make to your code. If you haven't started using it yet, this is your very first place to start. I happen to like using git, and since git is also the system that Drupal uses, it's a good choice if you're just getting started. However, there are other choices, and programmers can become very passionate about their preferred tool here. The point is, you need to have good version control so that you can track your own changes, and even more importantly, so that you have a good way of managing and merging together the changes of other developers.

If you're getting started here, there is an excellent video and article series about learning git over at github.

Features: from mouse clicks to version control

As I mentioned in the "why is this hard" section above, one of the big road blocks in good deployment is coordinating the changes in your database. Version control systems only see code, and while you can use a utility like mysqldump to export your database into a file, this is not a very workable method for coordinating those changes. There have been some very clever systems set up that handle database coordination in this way (such as the Database Scripts project, but this comes with it's own host of difficulties and very specific development strategies. Instead, the Features module has become the de facto standard for handling configuration in version control because most of the changes that you make on a site can be turned into a "feature" which is downloaded as a module, stored in code, and can be easily added to version control and passed to other developers and then switched on for your live site.

Not everything works with features unfortunately (an issue that I will address shortly), but there are a number of modules which either extend the Features module's capabilities or are themselves compatible with exporting data to features. Here are a few you will want to check out: strongarm, node_export, box, context.

The features module page has some good resources for getting started. It may seem a little intimidating at first, but really it's pretty intuitive once you start working with it.

"But X modules doesn't export to features!"

Unfortunately, there are still some things you can't do using the features module. There are a variety of approaches to this problem, but one that is capable of working for everything is the hook_update_N() functions that can be placed inside the .install file of a module. These functions run once when running update.php and provide a good way of updating things in your database that can't be updated using the features module. I'm not saying it's always easy to know what to put inside one of those hooks, but it is a viable way to take care of those pesky updates that won't export properly to a feature.

Drush is Your Friend

Chances are if you've been around the Drupal community much, you've read or heard about drush. Drush stands for DRUpal SHell and it is a command line utility that is an incredible powerhouse when it comes to being able to work faster with your Drupal site and automate all kinds of important tasks. Setting up a good automated workflow for your deployment environment can probably be done without Drush, but you don't want to try. If you haven't started working with drush yet, go get started with it today and I promise you that you'll thank me later.

From Drush to Shell Scripts

Once you have drush mastered, you'll quickly find that there are a number of commands that you execute, often together, some of which are hard to remember all of. Simple shell scripting can save time and avoid mistakes by grouping a number of drush commands into one file which you can execute with a few keystrokes. This will also be one of the final keys to getting a deployment environment up and running.

There are a lot of good introductory articles for getting started with shell scripting. Here's a straight forward one on getting started with bash.

Beyond the Basics

If you don't have your head around the tools mentioned above, start with those and don't bother moving on until you feel at least somewhat comfortable with them. With reasonable mastery of git, features, drush and shell scripting, you are in fact ready to put together a fully automated deployment environment. However, there are a number of tools and strategies that you should be aware of to really kick your deployment process into high gear.

Continuous Integration with Jenkins

Jenkins CI (formerly called Hudson) is an automation system for handling code builds. It is a very powerful tool and I won't go in to detail here, but what Jenkins can do for you is watch for when code is commited into your version control system and then automate processes from there. It can run tests, send files to your development server and do anything you can do in a script. It then keeps a log of any problems that are encountered and then notifies you or other developers if there is a problem. For advanced deployment setups, you will almost certainly want to have such a tool.

Testing: SimpleTest and Selenium

Above I mentioned that Jenkins can run tests. You can also run tests a number of other ways, the worst of which is spending hours upon hours clicking through your site to see if something is broken. Using SimpleTest, which is a part of Drupal 7, along with Selenium, can allow you to automate all of that testing and help you to catch all your errors before the changes go into production and you have frantic calls from customers who are no longer able to use their favorite feature of the site.

Drush Make

Another tool that has risen greatly in popularity recently is Drush Make, which as of Drush 5 is a part of the standard download. It allows you to have a single file (a "make" file) which describes all of the code, modules and patches in your site and makes for a straight forward way to keep all of your code in sync between multiple developers. It can also help you to keep a much cleaner and easier to follow version control repository.

Conclusion

In this article, I have described a tool set that will give you everything you need to build robust and powerful deployment systems. In my next article, I will lay out in detail my (currently) preferred deployment setup, but be aware that the ideal setup is likely to vary based on your project's needs, budget, system architecture and so on. If you get a good grasp on the tools above, you can lay out a deployment system that will work best for you, your team and your clients, and ultimately will make everyone happy and your website a wild success. Well.. OK.. it might not get all that done, but it will help you on your way!

var switchTo5x = true;stLight.options({"publisher":"dr-53823897-181c-4461-ae09-5adff87aeeb"});

View the discussion thread.