WF Tools FTW@ Pfizer



WF Tools FTW@ Pfizer

0 1


drupalcon-prague-presentation

DrupalCon Prague Presentation

On Github wftools / drupalcon-prague-presentation

WF Tools FTW@ Pfizer

Presented by Dave Hall & Tim Holt.

Who are we?

  • Acquia Technical Consultant
  • Drupalist
  • Systems Architect
  • Large Scale Migration Specialist
  • NOT Dries
Tim Holt's mug shot

Who are we?

  • IT Consultant
  • Drupalista
  • Webapp Hacker
  • Sys Admin
  • Fat opinionated [alternative to svn]
Look carefully at the photo and you'll realize it is staged. It was taken at Yankee Stadium when I was in NYC in May 2013.

<ins cite="http://intranet/policies">disclaimer</ins>

Disclaimer

This presentation outlines a general technology direction.  Pfizer Inc has no obligation to pursue any approaches outlined in this presentation or to develop or use any functionality mentioned in this presentation.  The technology strategy and possible future developments are subject to change and may be changed at any time for any reason without notice.

We're going to tell you a story.

Once upon a time,

a little boy called Dries lived in Belgium.

While at uni Dries had a little baby called Drupal.

Drupal started to grow.

Like many kids Drupal started doing odd jobs.

While at high school Drupal got a part time job.

Eventually Drupal made it to uni.

After graduating Drupal got a job in the media.

One day a big corporation rang and offered Drupal a job.

Drupal accepted.

On the first day Drupal turned up for work,

and it was clear Drupal didn't quite fit in.

Drupal was used to doing everything on production.

One day the boss called and told Drupal to go buy some new tools.

Drupal started searching for new tools.

The next day Drupal's new tools arrived.

Drupal's boss was impressed.

And they all deployed happily ever after.

What was in the toolbox that made Drupal's boss so happy?

UUID

Deploy

Services

drush

Features

git

Rules

Jenkins

Custom Entities

These tools allowed Drupal to do things very differently.

When Drupal was younger code went up and content came down.

Drupal realized that looking at content on staging was hard.

There was no easy to read log of all changes.

Drupal had difficulty looking at a single change on it's own.

Content and code changes couldn't be bundled together.

Deployment was an all or nothing event.

Deployments couldn't really be tested.

Different permissions and configuration per environment weren't possible.

This all made Drupal very sad.

Drupal decided to change how things were done.

Drupal discovered that arbitrary sets of changes could be bundled together.

Drupal decided to call this a "job".

Now Drupal can group code changes with content changes so both get promoted together.

Drupal can approve the changes in the job each step of the way, and log what's happened.

Drupal gave each job it's own dedicated sandbox.

Drupal can preview content in context.

Drupal can push several jobs to the staging server,

but only push a single job up to production when it's ready.

Drupal tests deployments at every step along the way!

Drupal can create, edit, preview and push content...

all without logging into production.

Drupal has a little cousin.

Drupal's cousin's name is "Job123".

Drupal makes sure job123 is safe on an epic journey.

Job123 started off as nothing more than a twinkle in somebody's eye.

First, Drupal spins up a new dedicated drupal sandbox called job123.dev.site.com.

Next, Drupal creates a job123 git branch and checks it out on the sandbox.

Drupal then creates a job123 deployment plan to track the content changes.

Drupal makes changes to content or code (or both) on the sandbox.

Now job123 is big enough to move to the integration environment.

Drupal merges the job123 git branch into the integration git branch and pushes it to the integration server.

Then Drupal triggers the job123 deployment plan to be pushed to the integration server.

Drupal sits back and looks at the changes merged into the integration server...

...and decides job123 is ready to move to the staging environment.

From there, the same merge/approval happens on staging before being pushed to production.

All of the jobs' statuses are tracked by Drupal.

Drupal can tell at a glance which jobs are in which environments, and which are ready for approval...

…all from a central management console.

This management console is the heart of WF Tools.

Meanwhile, Pfizer heard about what Drupal could do.

At Pfizer Drupal worked hard.

Drupal ran 300+ sites at Pfizer,

Each week brings around 3 new sites.

Pfizer needed Drupal's new toolbox.

Drupal's boss at Pfizer was impressed.

DEMO

The rolling releases model

allows people to go from idea to prod in an afternoon.

And they all deployed happily ever after.

THE END

Questions

Learn more

Connect with Dave

Connect with Tim

Feedback

If you liked our session go say nice things at https://prague2013.drupal.org/session/wf-tools-ftw-pfizer and click the take the survey link.

I you hated it, pretend you never saw this slide.

Copyright

WFTools FTW @ Pfizer by Dave Hall and Tim Holtis licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Australia License. Based on a work at wftools.github.io/drupalcon-prague-presentation.

Image Credits

Image credits continued...