Most development shops make use of a "development/staging/production" server model. Maintaining code, content, and configurations across multiple environments can be a bit tricky, and developing an effective, managed, workflow with multiple developers can be chaotic, if not impossible. This session would discuss introduce the development -> staging -> production environment model, how to effectively apply version control to manage workflow, and how to coordinate the moving parts involved in creating a managed, QA friendly release process, using Git, Drupal Install Profiles, and effective ticketing.

1. Nick Hepner
nick@SimpleInformation.com
@NickHepner

2. Managing
Deployments with
Git and
Install Profiles
Managing Code, Content, and
Configurations Across Multiple
Environments
…Part Deux

3. Nick Hepner
•Building web sites since 1998
Building Drupal sites since 2006
“Large Scale” Drupal since 2009
•Drupal Specialist
Data Migrations
Enterprise Scalability
Configuration Management
•Director Unallocated Space

4. Why am I here?
•Standard Deployment Model
•Code, Content, Configuration and their
workflows
•Using Install Profiles for configuration
management
•Deploying your code with Git

5. Standard Deployment Model
Content Staging
Developme
nt
Staging Producti
on
Local

6. Configuration
•Consists of Drupal admin and module
settings.
•Exportable site structures
Content Types
Contexts
Image Styles
•User Roles and Permissions
•Configuration workflow begins on the
development side of the model.
New modules installed
Existing modules configured

7. Configuration Workflow
Configuration
Developme
nt
Staging Producti
on
Local

8. Content
•User generated content
•User registration and accounts
•Content workflow begins on the production
server
User registrations
User generated content
Nodes
Entities
Files and uploads
Content management workflows.
Commerce
General site and user administration

9. Configuration Workflow
Developme
nt
Staging Producti
on
Configuration
Local
Content

10. Conflicts
•Servers no longer syncronized
Developers begin working and testing on
different setups
“Where is the most recent copy of the
database?”
•Data is at risk to be overwritten
•Forces many manual, time consuming
updates
•Most recent/accurate data set difficult to
keep track of

11. Code
•Code can be versioned for easy deployment and
management (Git, SVN)
•Does not conflict with database changes.
•Does not include database stored code.
•Follows same workflow as configuration –
originates from development side of model.

12. Exportables
•Building web sites since 1998
Building Drupal sites since 2006
“Large Scale” Drupal since 2009
•Drupal Specialist
Data Migrations
Enterprise Scalability
Configuration Management
•Director Unallocated Space
•World famous drinking buddy.

13. Install Profiles
•Used to package re-usable functionality
•Preconfigured Drupal distributions
Commerce Kickstart
OpenAtrium
OpenPublish
OpenPublic
Commons
•Provides convenient wrapper to store global
setup and configuration tasks.

14. Exportables
•Use Features and Ctools to export your configurations
into code.
This removes configurations from the
configurations workflow, and places them into the
code workflow with no database conflicts.
Content types and fields
Views
Contexts
Deltas/Panels
•The more things you can export now, the more time you will
save later.

15. Profile Setup
Use your .info file to set any modules or features
as requirements.
This will automatically enable them, which is useful for
especially useful for features.
In the .profile file, use the
hook_form_install_configure_form_alter() to
change the profile setup form if necessary.
The magic happens in the .install file!!

16. Profile Install Files
Use hook_install() can be used to set up initial configurations. This will run the
FIRST time the site is installed.
Use hook_update_N() to provide any later configurations.
Don't overwrite scripts in previous code – create an update hook with a
higher version number.

17. Code
De
v
Staging
Producti
on
Local
Branches Tags

18. Deployment
When deploying an update, use drush updb to run your update hooks
Can automate deploying git pushes using Jenkins

19. DevelGenerate
Use devel generate's functions to automate test data.
devel_generate_word()
devel_create_greeking()
devel_create_para()
Should be used to replace need for actual data.
Great for PII, PHI and high security sites.
Can still facilitate distributed develpoment.

20. Advantages
Very easy to test deployments to any environment.
Site rebuilds exactly the same way, every time, for all developers
Can manage configuration changes in Git.
No more question about the most recent data set.
Easier to project manage

21. The Future
Drupal 8 will use YAML to manage configurations. Configurations will be exported into
A lot of “one-touch” deployment features and setup.
D7 and D6 sites will still require maintenance.

22. Questions?
@NickHepner
nick@simpleinformation.com