Production is an Artifact of Development
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.
- 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 Acquia and 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