The tools that build the thing are not the thing itself. A production-ready Drupal repository is the product of our development chain.
Drupal project repositories include myriad development tools from a Vagrantfile to a Gemfile from Composer to Behat. We commit our SASS but deploy our CSS. We commit instructions to build the thing but deploy the thing.
As we look beyond the Drupal community for tools to test, deploy, package manage, and build our Drupal projects, the creation of our Drupal root is the output of the machinery that we use to build and test it.
I will walk through my development workflow that conceptualizes production as a product of development and thus a separate repository.
This includes:
Using Composer to manage project dependencies
Setting up an automated testing, building, and deployment environment with Travis and CircleCI
Automating the building of that artifact on an automation platform
Pushing that artifact, and only the artifact, to Pantheon
The audience for this presentations probably has:
An aversion to any site that hasn't exported their configuration as code
At least an understanding that a Drupal project should make their deployment strategy scriptable
Some familiarity with automation tools (Jenkins, Travis, CircleCI, etc.)
Some knowledge of Composer
Learning Objectives & Outcomes:
An understanding of this problem space
An introduction to how you might go about addressing separating your deployable Drupal from your Drupal development toolchain
Renewed energy for building deployable Drupal