A beginning web developer works directly on a live site. After bringing down the live site a few times or being embarrassed when unfinished work appears on the live site, the developer learns to use two environments: development and production.
This lasts until the first major revision of the website. At that point, the client wants to keep the old site running live but be able to preview the new site. The developer now has two options: have the client come look over their shoulder or introduce a third environment where the client can preview the new site. Now the developer has three environments: development, a staging or "preview" environment, and production.
Luggage works best with at least two environments, but you may have as many as you want.
Luggage heavily leverages drush, a command-line interface to Drupal. In the following sections, we will show you how to set up drush to make things easy when you work with luggage. Here's how we grab a copy of a database from the live production site and put it on a local development box:
$ drush sql-sync @example.live @example.dev
So much quicker than using PHPMyAdmin to export the database, then moving the export to your local box and importing it into your local MySQL server!
Keeping Aliases in Version Control
The information that drush uses, such as which websites you have and on which server they live, will be used more than once. Additionally, you'll want to keep track of changes that are made to your set of websites, especially if you are working on a team. Therefore it makes sense to keep your drush information in version control, such as a Git repository. We recommend using Bitbucket because private git repositories are free there. If you are on a team, you can make a Bitbucket team so that people on your team can add sites.
You can certainly also use Github or your own private repository if you have one.
We are talking here about your drush information. On an OS X development box, this will live in /Users/yourusername/.drush. On Linux it would be /home/yourusername/.drush. Both of these are, by convention, shortened to ~/.drush with the ~ meaning "your home directory."
It is best if the drush information is the same everywhere you work. On the servers you work with, it goes in /etc/drush:
Creating a .drush Configuration Directory
Let's assume that you want to create a .drush configuration directory and store the directory using git in a Bitbucket repository. Here's me creating a repository for my .drush:
Now that I have the repository created, a .drush directory can be created and pushed up to the repository.
The following shows me doing this at the OS X command line. Lines beginning with # are comments describing what the command on the next line does.
# Move to my home directory, /Users/john cd ~ # Make a .drush directory mkdir .drush # Move into the directory I just created cd .drush # Make this directory a git repository git init # Connect this new git repository with the one I created on Bitbucket # (obviously, substitute your own repository URL here) git remote add origin firstname.lastname@example.org:jvandyk/mydotdrush.git # Put the word 'cache' (without the quotes) into a .gitignore file. Drush will # create and use a cache directory but we do not want it in the repository echo 'cache' > .gitignore # Get this .gitignore file ready to be committed git add .gitignore # Commit the .gitignore file git commit -m 'Initial commit of .drush directory containing .gitignore' # Push the commit up to the remote repository on Bitbucket git push -u origin master