The development server is capdev.library.cornell.edu (aka sf-lib-web-006.serverfarm.cornell.edu). Each developer maintains a site, [netid].capdev.library.cornell.edu, on capdev. Look in /libweb/sites/ for your site.
Prepare the site for deployment
The deployment is based on the git repository for this site stored on git.library.cornell.edu. You have to make sure the repository accurately reflects your development environment before deploy.
- Update the drush make file.
cd mysite cul_capistrano/update_enabled_modules_list.sh
This script ends showing the differences between an automatically generated drush make file and your local.make.
Be sure the versions of contributed modules match between these two files. Edit the versions in drupal_config/local.make to make them match.
(The generated make use * for the drupal core version. You should use a specific core version in your local.make) - Run the make file to be sure all changes are in your dev site.
cd mysite cul_capistrano/do_make.sh
- Commit all changes to your local git repo
git status git add --all git commit drupal_config/ -m 'my enabled modules, themes and make files' git commit public/ -m 'my new drupal core, module, and theme changes' git commit --all -m 'anything else, like maybe config/ changes'
In real life you'll be committing each change as you go with an informative message attached to each commit, right?
- Push the local git repo to it's origin
git status git push
git status should return something like:
# On branch master
nothing to commit, working directory clean
Deploy a site
You can specify as many target remote machines as you like in your cinfig/deploy.rb set :stages directive, but normally there'll be staging (victoria02) and production (victoria01). Normally staging is set as the :default_stage so you don't have to specify anything on the cap command to target the staging server.
- follow the steps in "Prepare the site for deployment"
- deploy to the staging server (victoria02)
cap deploy
- or deploy to the production server (victoria01 or victoria03)
cap production deploy
What this does is clones the git repo to the target machine, moves all the site code to a timestamped directory there, updates a symbolic link pointing the document root at the new code, does the Drupal update.php procedure, reverts all features, enables all the modules enabled in the dev site, clears the cache, and a few other Drupal things. It makes a snapshot of the Drupal database before all this, but leaves the target database intact (except for the module updates), so the target site's new content is preserved.
Update Drupal modules
You can use several methods to update the modules. In Drupal, go to admin/modules/update and follow the instructions. On the command line do this:
cd mysite cd public drush up
You can also update the version numbers in drupal_config/local.make, then
cd mysite cul_capistrano/do_make.sh
Update Drupal core & modules
The best way is to update the Drupal core version number in drupal_config/local.make then run the make file:
cd mysite cul_capistrano/do_make.sh
Apply patches
The best way is to update the drupal_config/local.make file with the patch info:
projects[kaltura][version] = "2.0" projects[kaltura][patch][] = "http://drupal.org/files/kaltura-1567302-dispaly.patch"
then run the make file:
cd mysite cul_capistrano/do_make.sh
Copy a remote database to the dev machine
cd mysite cap production drupal:db:grab
Install a database dump on remote machine
cd mysite ls backup/ README.txt staging-snapshot-20140114162844.sql cap staging drupal:db:install -s file=backup/staging-snapshot-20140114162844.sql
Install a database dump on the dev machine
cd mysite ls backup/ db-features.test.library.cornell.edu staging-snapshot-2013-10-23-16-5-59.sql staging-snapshot-2013-10-28-11-44-8.sql local-snapshot-2013-10-24-16-19-52.sql staging-snapshot-2013-10-24-11-32-41.sql staging-snapshot-2013-10-29-10-57-19.sql production-snapshot-2013-10-30-12-35-22.sql staging-snapshot-2013-10-24-9-24-42.sql staging-snapshot-2013-10-23-14-17-14.sql staging-snapshot-2013-10-25-13-17-23.sql cul_capistrano/local_db_install.sh production-snapshot-2013-10-30-12-35-22.sql
Create a development branch
Merge a development branch
Prepare a new site on the dev machine
Make a git repo for the site on git.library.cornell.edu. Use the test site name, e.g. seadina.test.library.cornell.edu.
Run the script to create the initial site directory.
cd my_cap_dev_area setup_cap_dev_site.sh seadina_test_library_cornell_edu.git
Create the database, make a symbolic link from htdocs to the public directory (where Drupal is), install Drupal.
Then add everything to git, commit, and push.
Prepare a new site on a remote machine
cd mysite cap staging deploy:setup cap staging drupal:site_setup_permissions cap staging drupal:install -s db=databasename -s dbu=databaseuser -s dbpw=databasepassword \ -s d_user=Drupal_user#1 -s d_pw=Drupal_user#1_password -s d_email=Drupal_user#1_email
Update cul_capistrano
The cul_capistrano directory is a 'git subtree'. If the separate git repo cul_capistrano comes from has been updated you can update your copy:
cd mysite git subtree pull --prefix cul_capistrano git@git.library.cornell.edu:cul_capistrano.git master --squash -m 'merge cul_capistrano updates'
Undo a site deploy
cd mysite cap staging deploy:rollback
Note: this also restores the database to the state it was at before the previous deploy.
List all the capistrano commands
cd mysite cap -T
Enable passwordless login to remote machines
drush dl drush_extras drush pushkey victoria02.library.cornell.edu drush pushkey victoria01.library.cornell.edu drush pushkey victoria03.library.cornell.edu