Pantheon workflow models

To help prevent the need for hot-fixes, and also to allow us to push specific commits to live, we leverage multidev + local development to much satisfaction.

I like to think about Pantheon workflows as mutable through the project lifecycle.

Not all projects will go through every phase, but here is a chronology, with latter phases demonstrating the announced philosopy:

DEV -> SNAPSHOT

Early project days. dev jam sessions. 

TEST stores snapshots of working code

DEV <-> TEST <-> SNAPSHOT

Things are less flaky and we release working code to LIVE periodically. 

The DB may still move upstream.

TEST is a volatile play space, as it should be.

LOCAL > INTEGRATION <-> TEST

in early project days, things are happening fast and furious. 

DEV is a space for integration

Push push push… if DEV's ok, up to test asap. Sometimes the DB goes upstream!

Once we get to the point of releasing a snapshot to LIVE, we initialize multidev, as below.

here is where it gets interesting…

LOCAL \  TEST <-> LIVE

      \  SPRINT /

DEV is dead to us.

Clients can experiment on TEST because its a mirror of live.

SPRINT is an integration branch and acts as an integration/dev space.

Anything that’s good to go mid sprint gets cherry-picked to master and up to TEST for final QA, then LIVE. These are generally QA’d on SPRINT already so we don’t clog MASTER up and require a hotfix.

SPRINT is merged to MASTER end of sprint and deployed after client TESTing

The rubber hits the road on LIVE, and if a bug comes in we can squash them Kanban-like on MASTER while we continue SCRUM on our SPRINT branch unimpeded, merging MASTER back into SPRINT with spirit

        FEATURE

LOCAL > FEATURE > INTEGRATION <-> TEST <-> LIVE

        FEATURE

where FEATURE branches are multidev environments that act like multiple TEST environments

As approved these move to an integration branch – often our SPRINT branch

DEV, again, is dead to us

TEST is for final client QA before release

Cherry picking may occur