sacha chua :: living an awesome life

When Jennifer Okimoto pinged me about possibly putting together a presentation for Web 2.0 Expo 2009 in San Francisco, I perked up at the possibilities. I had been intimidated by the list of previous sessions (who am I to tell all these experienced techies and businesspeople about Web 2.0), but Jen and I could definitely share lots of lessons learned about Web 2.0 in a large enterprise, bridging generations and geographies.

So I started a Google Doc for the abstract. After several invitations, she finally got access to it, and we brainstormed and refined our abstract through the shared document. It was a lot of fun, particularly coming up with a good title. I think my fondness for alliterative, catchy titles showed: "Linking the Leviathan?" "Moving the Mountain?"

This should be easier, though. I should be able to right-click on a person in our instant messaging client and say "Collaborate", pick a document, work on it in realtime, be able to invite other people in, and have that persist.

Someday…

I feel a bit nervous. There's a lot of shifting around, and lots of things I wonder about, too. I'm starting to feel a little unraveled around the edges, which is usually an indicator that I haven't been doing enough writing and reflection. There's a little bit more left to the Innovation Jam, some more work on my project, and then there's some more time to rest.

Running on hugs, cough lozenges, and more hugs.

I got caught up in IBM's Innovation Jam, and I hadn't realized that my blog was somewhat broken.

Oops.

I've disabled a great number of third-party things, including the Twitter Tools feed that made everything go haywire.

Which widgets would you like back?

• Update build and deployment plan
• Refine alert behavior for Drupal site
• Participate in IBM's Innovation Jam
• Paperwork: expenses, time, overtime
• Write about lesson 2 from Johnny Bunko: build on your strengths
• Cut second set of pieces for sewing
• Write about Emacs

Our configuration management discipline paid off last week, when we rolled out lots of bugfixes onto our production server. I used my deployment script to test the release-1 branch against our regression tests and copy the source code to the production server after it passed. A quick database update later, and everything worked without a hitch.

Why did it work? Here's what's behind our build system:

• We have a branch for release-1 bugfixes and a trunk branch for new features. It's easier than cherrypicking features to push to production.
• Module .install files handle all behavior-related changes (variables, new modules, etc.). Drupal can automatically apply those changes during the database upgrade process. Even the process of enabling a module is done through an update function in our main module's .install file. Note that the module install files are called in alphabetic order, so you may need to think about the sequence of functions.
• The Simpletest framework for unit and functional testing allows us to write regression tests that minimize risks of updates.
• Updates and tests are always run after a stripped-down copy of the production database is loaded, and are also occasionally tested against a full copy of the production database. This makes sure that the changes will cleanly apply to the production server. Domain Access complicates things a little because the domain name is encoded in the database, so my deployment script also takes care of substituting the correct domain name.
• To automate testing and upgrades, we use the Drupal Shell (drush) module in our local and QA environments.
• I wrote a deployment script webpage that provides a form for managing database changes and source code deployments to our QA server and to our production server.

I think it's pretty darn good. What would make it even awesomer?

• An updated deployment plan. I'm going to work on this document later.
• Testing before commits, instead of after. maybe I can set up a pre-hook on my own system, or use Emacs to do this somehow.
• Buttons to get full copy of database for local, QA. Full copies of the database take much more time, but are useful for getting a realistic feel for the functionality.
• An article on how other people can get up and running with this kind of thing. DeveloperWorks, maybe?

Technorati Tags: deployment