You are hereRecent posts
Recent posts
Updated: Zero-touch deployment with Aegir and Jenkins
This is an update to a previous post
Just a quick recap for those unfamiliar: I've been looking for a "zero-touch" development-staging-live workflow for Drupal, that would allow me to quickly roll out new Drupal platforms, and even migrate existing sites to those new platforms. I store all of my platform make files in a single Git repo, with branches like "live_platform1" and "dev_platform1". Ideally, I could commit a change to a makefile, and immediately my Aegir server would build a new platform based on that changed makefile and even migrate sites on the existing platform to the new platform.
mig5 has an excellent post describing a zero-touch workflow for Drupal- however, I needed to modify it a little to suit my needs. Note that this currently can build platforms, but not migrate sites.
First, I created a Jenkins project called "aegir_platforms", and added a string parameter "BRANCH". I entered the URL of my Git repo, and used "$BRANCH" as the branch identifier. Finally, I entered the following shell command:
/usr/local/bin/deployment.sh example.com ${BRANCH} dummyprofile dummywebserver dummydbserver ${WORKSPACE}/build.make ${BRANCH}_${BUILD_NUMBER} ${BUILD_NUMBER}
Zero-touch deployment with Aegir and Jenkins
There's a newer version of this post- the post on this page is maintained for historical purposes only
Just a quick recap for those unfamiliar: I've been looking for a "zero-touch" development-staging-live workflow for Drupal, that would allow me to quickly roll out new Drupal platforms, and even migrate existing sites to those new platforms. I store all of my platform make files in a single Git repo, with branches like "live_platform1" and "dev_platform1". Ideally, I could commit a change to a makefile, and immediately my Aegir server would build a new platform based on that changed makefile and even migrate sites on the existing platform to the new platform.
mig5 has an excellent post describing a zero-touch workflow for Drupal- however, I needed to modify it a little to suit my needs. Note that this currently can build platforms, but not migrate sites.
First, I create a Jenkins project with a name that matches a branch in my repository, such as "dev_platform1". I use a similar configuration to the one described above, but with the following shell command:
/usr/local/bin/deployment.sh example.com ${JOB_NAME} dummyprofile dummywebserver dummydbserver ${WORKSPACE}/build.make ${JOB_NAME}_${BUILD_NUMBER} ${BUILD_NUMBER}
Of course, I needed to modify the deploy.sh and fabfile.py to take into account the new parameter, since I like to name my jobs something nicer than just a date string. Contact me if you want me to post a copy of those files.
Note that I also had to create an SSH key to allow the Jenkins user to log in as the Aegir user, and specify this key in fabfile.py using the env.key_filename parameter.
Then, I just needed to set up a Git post-receive hook to notify Jenkins of changes to a branch (platform):
MS completed, plans for next semester
I'm happy to report that I passed my thesis and oral defense examinations and will be receiving my MS this month! A copy of my thesis is available on the MAHI Lab website. Next semester I will be studying abroad at the University of British Columbia, working on the Haptic Creature project with Karon MacLean. I'm very excited to get to explore a new city (especially one so close to the mountains!), and to try my hand at a new project. I'm still planning on completing my PhD at Rice, starting in Summer 2011.
How to market yourself online and build a personal website
A few weeks ago I taught a 3-hour mini-course for the Rice Center for Engineering Leadership titled Marketing Yourself Online: Building Your Personal Website. Feedback was very positive, so I thought I would post a copy of my slides for anyone who's interested (unfortunately no recording was made).
Note that some images are copyrighted by other individuals and used in this presentation in accordance with Fair Use doctrine.
"One click" duplication of a live Drupal site to a development site
I've come up with a nice script and group of settings that allow you to easily duplicate a live Drupal site. This is very useful if you've got a development site that perhaps you want to "reset" to the current version of the live site after you've finished development of a feature or (more likely) borked the installation completely. The general strategy is to dump a copy of your live db, empty the dev db, and import the data from your live db, and finally follow the same procedure for the associated files.
First off, you'll need to have a database and db user with appropriate permissions already set up for your development site. You'll also obviously need to have your web server / DNS set up for your development site. Got it? Good! Now go download and enable the backup_migrate module on your live site. Configure it to automatically dump a copy of the database to your files directory every night (or whatever schedule you prefer). Be sure to exclude the data from all of the cache tables, and from the notifications_queue table (if you are using the notifications module)- otherwise users might get duplicate notifications from your dev site. You could probably use a script to mysql_dump the database and exclude these tables instead of using backup_migrate- whatever works for you.
Now you need to modify your settings.php to automatically pick the appropriate db settings based on the current virtual host. This is very important - otherwise, when you copy your live site to your dev directory, you'll still be modifying the live db! Use the following code to dynamically pick the appropriate db settings:
if ($_SERVER['HTTP_HOST'] == 'devsite.example.com') {
$db_url = 'mysql://db_dev_user:db_dev_pass@localhost/db_dev_name';
} elseif ($_SERVER['HTTP_HOST'] == 'example.com') {
$db_url = 'mysql://db_user:db_pass@localhost/db_name';
}
Update: site management using proto-sites
Hot on the heels of my previous post on site management using proto-sites, Greg Anderson pointed out that you can lock modules in the latest release of Drush, allowing you to maintain "hacked" and stock modules side-by-side on your proto-sites. Moreover, he wrote a patch to the Hacked! that allows you to automatically lock hacked modules. This means that you can run one command on a proto-site with both hacked and stock modules that will quickly update all of the stock modules while holding back the hacked modules so they can be updated via vendor branching or whatever other method you prefer - all without any special effort on your part!
If I have to hack a module, I move it out of the proto-site directory and into a SVN repository where it can be vendor-branched, and then place a symlink to the module in the proto-site directory. This way I can re-use hacked modules on many different proto-sites.
Here is the modified script that will update module code on a proto-site (holding back hacked modules) and then run update.php on all dependent sites:
drush-update-all
#!/usr/bin/env bash
drush up --lock-modified
installpath[1]=/var/www/drupal/research
installpath[2]=/var/www/drupal/personal
installpath[3]=/home/client1/research
installpath[4]=/home/client2/research
installpath[5]=/home/client3/personal
installpath[6]=/home/client4/personal
for index in 1 2 3 4 5 6
do
filepath=${installpath[index]}
printf "Updating %s\n" "$filepath"
cd $filepath
drush updatedb
drush pm-refresh
done
Manage multiple Drupal sites efficiently using Drush and "proto-sites"
While the amount of documentation and support surrounding Drupal as a whole is fabulous, there's a surprising dearth of information regarding management paradigms. Lots of people talk about small parts of the puzzle, like using SVN and vendor branching to track custom changes to modules, but there's not a lot of talk about how to efficiently manage large numbers of Drupal sites. So I figured I would share the architecture that I came up with, in the hopes that it'll help other maintainers as well!
How Contexts will rock your Drupal world (and why they should be in core)
In case you've been living under a rock for the past two years (or slaving away in a dark underground lab like me) and haven't heard about Contexts, give me two minutes of your time and allow me to explain why they rock and how they fill some gaping holes in Drupal core.
The easiest way to think of Context is like Triggers and Actions for your theme - except instead of Triggers and Actions, you have "Conditions" that define a context and "Reactions" to take when those conditions are met. The archetypal Context is a set of Conditions and Reactions that, if put into English, would read "If the user is viewing a Blog entry, show a block listing the immediately adjacent entries." This might sound like a trivial example just as easily accomplished with Panels or (gods forbid) core Blocks rules, so let me give you a more compelling and personal example.
For better or for worse, a lot of websites serve dual purposes: a public-facing side serves to disseminate information, garner publicity, etc..., while a protected area serves as an intranet, with tools for project management, team calendars, etc... (think Open Atrium). Security concerns aside, I think this is a setup that works very well in a large number of (ahem) contexts, as it allows for easy sharing of data and resources and graduated escalation of privileges and access to those resources.
The problem is that what you want a prospective client to see when linking in from a Google search is drastically different from what you want to see while managing tasks and projects, and is different still from what you want to see while building out your site. (In case you haven't figured it out, I'm talking about you and me here!)
Welcome to the blog (and new website)
It's interesting how popular blogs used to be, and how they've almost completely fallen out of fashion (at least among my generation) in favor of 140-character status updates, "likes", and retweets. I think having a little more space to share a story or form a cohesive argument is kind of nice, so I'm going to give it a shot once more. Also, as more of my friends are graduating, transferring, or generally fleeing Houston to new and greener pastures (and honestly who could blame them!), many seem to drop off the face of the virtual planet. I'm hoping that by sharing my experiences and adventures I can lead by example and convince more to do the same.
I expect this will be a fairly assorted mix of trip reports, philosophizing, and musings on Drupal and haptics. I'll try to keep it interesting and not alienate anyone... too much :)