Docman - The swiss army knife for Drupal multisite docroot management and deployment

DOCMAN
The swiss army knife for Drupal multisite
http://corp.adyax.com/themes/adyax/logo.png
docroot management and deployment
A L E K S E Y T KAC H E N KO A N D A L E K S A N D R T O L S T I KOV
D E VO P S H T T P : / / B I T. LY /DOCMAN20 1 4

WHO AM I
Oleksiy Tkachenko
http://corp.adyax.com/themes/adyax/logo.png
PM, Drupal architect
With Drupal from 2007
With Adyax from 2009
France / Ukraine

LARGEST DRUPAL SHOP IN EUROPE
350 PROJECTS
150 DRUPALERS
7 YEARS OF GROWTH
10K HOURS PROJECTS

http://corp.adyax.com/themes/adyax/logo.png BEFORE WE START

/ VAR / WWW
DOCROOT?
Acquia: your docroot folder is the root-level of your Drupal
installation and its websites and contains its files and directories,
including Drupal's index.php, includes directory, and modules directory.

PROBLEM 1:
Multiple suppliers need to work with one multisite installation

PROBLEM 1:
Deployment is painful - fatal errors, incompatibility
Production environment - never stable
How to merge and integrate the work of multiple people?
How to merge and integrate the work of multiple teams?

PROBLEM 2:
Standard modules, best practices and team discipline

PROBLEM 2:
No development standards. Panels? Contexts?
Standards exists, but not respected
Drupal best-practices are not respected
Modules in /all or in /default?
No team discipline (features are overridden, environments omitted,
etc)

PROBLEM 3:
Who should update Drupal?
What modules needs to be updated?
What is happening in my docroot?
What are the latest changes and stable versions?

PROBLEM 4:
When to run tests?
How to run tests?
In which environment?

PROBLEM 5:
Cloud hosting usually is very limited in multisite management

INTRODUCING DOCMAN
http://adyax.github.io/docman/
# gem install docman

SCHEMA
GIT:
PROJECT A
DOCROOT
GIT:
CORE GIT:
SITES
GIT:
CLOUD
HOOKS
DOCMAN
GIT:
PROJECT B
GIT:
COMMON
GIT:
PROFILES

config.yaml
---
environments:
dev:
deploy_target: git_target
state: development
target_checker:
handler: :ssh
file_path: /mnt/www/html/subscription_name_dev # Edit this!
ssh_host: staging-xxxx.prod.hosting.acquia.com # Edit this!
ssh_user: subscription_name # Edit this!
test:
state: staging
target_checker:
handler: :ssh
file_path: none
file_path: /mnt/www/html/subscription_name_dev # Edit this!
ssh_host: staging-xxxx.prod.hosting.acquia.com # Edit this!
ssh_user: subscription_name # Edit this!
prod:
state: stable
tagger:
enabled: true
handler: :option

master/common/info.yaml
status: enabled
type: repo
repo: git@this-is-your-git-host:common/common.git # Edit this. This is your repository
with common modules for everyone.
order: 30
states: # Git flow!
development:
type: branch
version: develop
staging:
type: branch
version: master
stable:
source:
type: :retrieve_from_repo
repo: :project_repo
branch: state_stable
file: info.yaml
hooks:
builder:
after_execute:
- type: :script
location: $INFO$/after_build.sh
execution_dir: $PROJECT$
params:
- environment
Common code repo
described

master/docroot/info.yaml
type: repo
repo: git@this-is-your-git-host:common/drupal-core.git # This is your Drupal repo.
order: 1
states:
development:
type: branch
version: master
staging:
type: branch
version: master
stable:
type: branch
version: master
hooks:
builder:
after_execute:
- type: :script
location: $INFO$/after_build.sh
execution_dir: $PROJECT$
params:
- environment Drupal core repo
described

master/projects/project1/
info.yaml
type: repo
repo: git@this-is-your-git-host:project1.git # Edit this. This is your project repository
with custom code.
states:
development:
type: branch
version: develop
staging:
type: branch
version: master
stable:
source:
type: :retrieve_from_repo
repo: :project_repo
branch: state_stable
file: info.yaml
location: $PROJECT$/tools/deploy/$ENVIRONMENT$/after/after.sh
execution_dir: $ROOT$/docroot
params:
- environment
- type: :script
location: $PROJECT$/tools/deploy/common/after/after.sh
execution_dir: $ROOT$/docroot
params:
- environment
Project code repo
described (not fully)

REPOSITORIES: CORE
Drupal 7
!
!
!
Branches:
develop
master
state_stable

REPOSITORIES: SITES
SITES
/all
/default
/site_a
/site_b
sites.php
Branches:
develop
master
state_stable
https://github.com/Adyax/docman-sites

REPOSITORIES: PROJECT
PROJECT A
/modules
/themes
/libraries
Branches:
develop
master
state_stable
https://github.com/Adyax/docman-project

!
!
!
!
REPOSITORIES: CLOUD HOOKS
/common
/dev
/prod
/samples
/scripts
/test
README.md

FEATURES
Focused on cloud hosting: Acquia Cloud, Pantheon and others, but not
limited to.
Clear separation of the websites code in multisite environments
Incremental pushes of the finished docroot to the cloud hosting
Code separation for easy deployment

FEATURES
Drupal version agnostic Drupal 8 ready!
Force people to keep features by default, updb, features revert, registry
rebuild on each push to environments
IF SOMETHING HURTS, DO IT MORE OFTEN.
http://evan.bottch.com/2010/05/26/continuous-integration-if-something-hurts-do-it-more-
often

FEATURES
Multiple docroots to support? Not a problem!
Stable & versioned production environment
Jenkins friendly workflow
Deployment pipelines organisation (with Jenkins integration)
http://www.infoq.com/minibooks/continuous-delivery-overview
Different deployment scenarios achievable through config:
Continuous integration
Continuous delivery
Continuous deployment

LOCAL ENVIRONMENT
# docman build local development

DEV + STAGE ENVIRONMENT
# docman build git_target staging
# docman build git_target development

LIVE ENVIRONMENT
# docman build git_target stable

AVAILABLE COMMANDS
$ docman init <dir> <config-repo>
!
$ docman build <target> <env>
!
$ docman bump stable
!

AVAILABLE HELPERS
CHANGELOG file in each repo
automatically generated using
commit comments
!
VERSION file in each repo
automatically generated with the
latest version (all branches)
!
info.yaml files everywhere helps
you with what is what

CASE STUDY 1: BEFORE
INITIAL CODEBASE
CLONE
SITE 2 CODEBASE SITE 3 CODEBASE

CASE STUDY 1: PROBLEMS
Conflict with Features (modules) on the cloned website
Manual deployment for each website
Pain to maintain
Standards? Which one?
Code duplication

CASE STUDY 1: AFTER
GIT:
SITE A
DOCROOT docman
GIT:
SITE B
!
GIT:
CORE СOMMON
git GIT:
SITES

CASE STUDY 2: SERIOUS
Global company
Drupal is a company level standard for websites (yay!)
At least 3 different Drupal shops independently delivering websites
constantly

CASE STUDY 2: PROBLEMS
At least 3 different Drupal shops independently delivering websites.
Maintenance? Each agency defines.
Standards? Each agency defines. (Panels? Context?)
Deployment? Approach is different per agency (capistrano, manual, ftp,
you name it).
Hosting is in the same place but each time configured differently

CASE STUDY 2: SOLUTION
GIT:
SITE A
GIT:
SITE B
DOCROOT Acquia Cloud
!
GIT:
CORE COMMON GIT:
SITES
GIT:
CLOUD
HOOKS
INTEGRATION PLATFORM
git hooks >
Jenkins > docman
Gitlab

http://corp.adyax.com/themes/adyax/logo.png DEMO TIME

ROADMAP
@Todo: Vagrant image generation per website for easy local
development
@Todo: wizard to generate repository with configs
@Todo: Documentation

NEED HELP
@Todo: Config templates for various cloud hosting systems
@Todo: Better config error handling
@Todo: More deployment targets
@Todo: More docroot templates (Pantheon, Aberdeen Cloud, etc)

http://corp.adyax.com/themes/adyax/logo.png WHAT DID YOU THINK?
E VA LUAT E T H I S S E S S I O N - http://bit.ly/docman2014
FOLLOW US @ADYAX
FOLLOW ME @SHUMUSHIN

Docman - The swiss army knife for Drupal multisite docroot management and deployment

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Docman - The swiss army knife for Drupal multisite docroot management and deployment

Similar to Docman - The swiss army knife for Drupal multisite docroot management and deployment (20)

Recently uploaded

Recently uploaded (20)

Docman - The swiss army knife for Drupal multisite docroot management and deployment