oduilr.org goes live

This has been a busy week bringing http://www.oduilr.org live. Earlier, I wrote an article about developing an Open Outreach Drupal 7 based site for my church. This summer, I joined ODU Institute for Learning in Retirement and joined the communications and technology committee. At the first meeting I found myself volunteered to become webmaster and committee chairman as both incumbents were eager to move on to other roles.

The old site at http://legacy.oduilr.com was originally developed in the early days of ODUILR using Microsoft Front Page. The site had a dated look and was difficult to update. It was appropriate in the club’s early days but now that we are 700 members and 100 or so programs, social events, and trips per year, the organization has outgrown the old site.

Open Academy Drupal 7

Having developed the UCN site using Open Outreach, I looked around for a Drupal 7 distribution well suited to ILR’s needs and found Open Academy developed for University of California, Berkeley and maintained by System Seed. The site was designed to be a department maintained departmental web site with pages for each professor and class. The site had a nice course catalog, event calendar, and publications catalog presented in a pleasing manner using Panoply page layout.

First Try at our Legacy Host

These features were a good match to our initial design so the next step was to build a prototype for evaluation in a sandbox. I originally tried this by doing local development, moving the code base to a subdomain at our current host, and spinning up a database instance for the subdomain. We quickly discovered that the legacy hosting company provisioned too little PHP memory to run Drupal 7 and offered no managed hosting plans with adequate PHP memory.

Their solution was to pay the big bucks for a raw virtual server and manage it ourselves. No, I’m a retired moocher modeling and simulation puke with no desire to manage hosts visible to the public Internet and the Chinese, Koreans, Iranians, Russians, NSA and other bad actors of the Internet. So it was time to look for something else, Pantheon.

Pantheon Systems

The drupal.org distribution page provided a link to Pantheon where you could create a test instance of Open Academy and test drive it. In July, I built a test site and put the summer class catalog in it. It seemed to work well so I moved the content over from the legacy site and invited the board to take a look. It was this site that I tried to port to our legacy host and found that the legacy provider came up short.

Pantheon Systems (http://getpantheon.com) is a next generation hosting company designed specifically to host content management system based web sites. Pantheon started out as a Drupal 7 host but have since expanded to offer Word Press. Pantheon offers several curated Drupal 7 distributions including Open Academy, Open Outreach, and CiviCRM Drupal 7. Several things distinguish Pantheon.

Each site includes development, test, and live environments
GIT revision management, SFTP, and DRUSH are standard
Each site starts with automated provisioning followed by a GIT pull from the upstream master GIT repository
GIT is used to apply updates and manage local changes
Each hosting plan has adequate resources to run Drupal 7 correctly
Hosting plans scale from small personal sites to Internet scale
The business model focuses on easy development and deployment using Drupal 7 best practices
The support staff is actually helpful within Pantheon’s stated scope of supply
The support documentation is clear, concise, and task oriented
The site management UI is clean and uncluttered
Sites run in Linux containers that contain everything needed by the site and are provisioned with adequate memory, CPU and storage to run the site at the purchased scale.
The live environment supports both IPv4 and IPv6.
Pantheon’s standard hosting plans support personal scale, mid-sized businesses, large businesses
Pantheon offers custom service level agreements for national and internet scale clients

Prototyping at Pantheon

Pantheon lets an E-mail address have a free development sandbox supporting two sites. Developers use the Pantheon dashboard to spin up one of the curated sites from its upstream GIT repository or import an external site’s code, files, and database. For our development, we built Open Academy from the GIT repository and built all of the content in the development site. As it became useful, I invited the committee chairs to review the site and suggest corrections and additions. By October, the site was far enough along to request permission to engage Pantheon to provide hosting.

Going Live at Pantheon

At November’s meeting, the Board authorized the communications and technology committee to engage Pantheon to provide a personal site, register oduilr.org, and take the site live. Going live is a simple process

Arrange payment
Run launch checks and clean up any gripes
Clone development to test and test to live
Set up Live in your DNS

All of this is straightforward following Pantheon’s excellent instructions but took some time as our treasurer needed to change transaction limits on one of our cards, we couldn’t locate the card, and needed to obtain a replacement. Once set up with a card, Pantheon charges payment monthly, for us $25, sends a charge reminder and charge receipt. These can be sent to a billing contact rather than the site technical contact or site owner contact.

Pantheon also has an invite the owner to pay feature which allows an owner to set up payment for a site without disclosing the payment credentials to his web development company or web developer. This developer initiates the process on the proper (live) environment but each environment can be mapped for a fee.

Maintenance at Pantheon

Once a site goes paid, the development and test environments remain available.

The live environment is used to develop content.
The dev environment is used to apply updates and develop local modules
The test environment is used to verify the new code with the live content

Most folks put the live site on scheduled backup and perform manual backup on their dev and test sites. Normal GIT workflow applies. Pull and merge the upstream, make changes locally, commit them, and push them to the site upstream. Clients are not committers to the GITHUB curated distributions preventing a project from contaminating the master versions.