« Previous - Version 15/37 (diff) - Next » - Current version
Andrew Mallis, 04/23/2012 08:29 pm
more precise multisite instructions


Welcome! This page is your one-stop shop for getting started developing for the FGA project.

We're assuming that you are experienced with Drupal.

Contact Information


Our code exists simultaneously in 2 environments Github (public) and Pantheon (restricted access). The live server is running off the Pantheon MASTER branch.


FGA has an organization on github and the following projects are currently manifested there:

However, the production workflow for FGA is happening in Pantheon. Github is currently used only to manifest our codebase publicly. Drupal files and the database are also key to instantiating a local development copy, and these can be most easily made accessible via Pantheon.


Pantheon is a hosted development and deployment platform. For addition support, please seee their help desk


FGA developers should register for Pantheon if they haven't already. Registration is free and can be done here

Once registered, send an email to info [at] assembli.es requesting to be added to the TEAM, and specify which project(s) you're joining as well as the email address associated with your Pantheon account.

Pantheon workflows

local development set-up

The Pantheon workflow promotes local development. There is lots of documentation out there describing how to set up a local installation. We'll defer this question to the www to limit the scope of this wiki (external links welcome).

Once you've got the codebase checked out, create your own site inside sites, with a dedicated settings.php file. The git stack does track sites/default/settings.php, but decouples the database connect array. This allows us to add and track our own variable overrides and configurations. To keep your multisite container from being tracked by git you can simply add an entry to your home folder's git ignore policies (located in ~/.gitignore) like so:


You can also add something more catch-all like:


One advantage of running your own multisite instance is that you can create a modules folder in there, and test locally before moving things to sites/all/modules. everything inside your local site will be ignored by git.


Once you're on a project, its drush aliases will be packaged for you on Pantheon, and be accessible from your account page:

If you haven't used drush aliases before, you'll be impressed when you see them in action.

The file you download will be called pantheon.aliases.drushrc.php
I have mine in ~/.drush/aliases/pantheon.aliases.drushrc.php alongside my aliases.drushrc.php file.
Test your aliases with

$ drush sa

From your local environment, you can synchronize the development database like so:
$ drush -y sql-sync @live.fga-directory.gotpantheon.com @directory.occupy.local
(replace directory.occupy.local with whatever you call your site containing your local settings.php)

Synchronize the files from the production instance to local:
$ drush -y rsync @live.fga-directory.gotpantheon.com:%files/ @directory.occupy.local:%files $ drush cc all

You can also simplify your aliases with your own entries in aliases.drushrc.php like directory.local, directory.dev, etc.

$ drush -y rsync @directory.live:%files/ @directory.local:%files

More info on Drush aliases on Drupal.org

Managing the Pantheon–github relationship

Here's the contents of my local .git/config to manage the integration between the Directory in Pantheon and github:

    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = git@code.getpantheon.com:97d52c78-0b43-45a2-9d65-20c8a431706b
[remote "github"]
        fetch = +refs/heads/*:refs/remotes/github/*
        url = git@github.com:fga/fga-directory.git
[remote "all"]
        url = git@github.com:fga/fga-directory.git
    url = git@code.getpantheon.com:97d52c78-0b43-45a2-9d65-20c8a431706b
[branch "master"]
    remote = origin
    merge = refs/heads/master
git pull --rebase

comes from Pantheon. Note that we generally prefer the use of git pull --rebase, as it avoids ugly merge commits. This works approach works unless we start doing complicated feature branching (this article explains a more robust technique, if you're interested - we're not using it).
Or, pull from github with the remote:

git pull --rebase github

You can

git push all

to hit both github and Pantheon at the same time. Unless you have a reason not to, run the above command for every upstream push!

I don't recommend pulling from all, because it won't merge well, as git is too busy shuffling the deck to merge that process properly.
Pull one, then the other and both github and Pantheon will merge nicely.

It's important to note that only code in Pantheon can be pushed through the dev-test-live workflow. For now, that's where everyone is rolling, but if we want to develop more publicly, it might be desirable to work in github de facto. Our hope is that an auto-integration tool between github and pantheon will emerge so that we can update one from the other, so that you can just push to github, and that will push to pantheon dev. We'd need to

Features sometimes seriously reshuffles stuff, so merging isn't always obvious and you want to know asap if features have been modified and github pull requests can work well for this.

Development workflows

Drupal development for our projects employs a Features (Drupal.org documentation) workflow on git. We're exposing code to the public on github, but are actively developing on Pantheon

This is where you should be theming, and toying around, and rolling new features.

When you push from your LOCAL git repo to Pantheon, the DEV instance will automatically get updated. Awesome.

Features when re-rolled can sometimes arbitrarily re-order code blocks, or change indentation. Multiple local developers affecting the same Feature can sometimes loose much time resolving complicated 3-way merges. In these instances, work can often most easily be performed on the DEV environment, then Features re-rolled from there via the UI and committed from LOCAL. Git commits can't happen on the server itself (Pantheon does not provide shell access).

Content is pulled downstream, and code is pushed upstream from DEV. Non-featureized

New content should be entered here sites. Sites that aren't launched yet and in active development can see content entered on DEV. Upstream pushes are then seen as snapshots. Each push from the Pantheon interface creates a tag.

Generally speaking, hotfixes should not happen on LIVE. Any overridden Features are subject to being reverted.

Branching and Tagging model

Pantheon creates a tag for each synchronization between environments. Topic or feature branches are a good idea for development, but Pantheon can only run off the Master branch in all 3 environments.

pantheon-team-ex.png (64.9 kB) Andrew Mallis, 04/08/2012 02:50 pm

dl-pantheon-aliases.png (45 kB) Andrew Mallis, 04/08/2012 03:46 pm

pantheon-download.png (24.9 kB) Andrew Mallis, 09/06/2012 03:07 pm