Website Deployment Process

Purpose

This page is meant to document the development and deployment flow for the DDI website. This assumes you have a working knowledge of Drupal 8Drush, and access to the hosting provider.

Requirements

You should have Drush running locally. Since we do not yet support a Composer-based (#2945910: Migrate to a Composer-based Drupal) installation on our hosting provider, you will need to make sure that you have Drush installed globally on your machine. As of March 9, 2018, the recommended version is 8.1.16.

Having access to our hosting provider, please download the Drush aliases file. This will let you run Drush commands on the dev, test, and production environments. More details on that process is available on the Pantheon Drupal Drush Command-Line Utility doc.

Local Development

We use Configuration Management to deploy configuration changes upstream from local (to dev, test, live). In the process of getting your local environment working or preparing to push configuration changes from a lesser environment to production, please make sure you export your configuration.

drush cex -y

You can validate the git difference here and make sure that you are only pushing configuration that you want into git. Similarly, when you pull the latest code make sure that you import another developer's configuration into your local database.

drush cim -y

You can remove the -y parameter to approve each configuration. If you make manual changes to configuration, please make sure that we have this exported into the appropriate configuration YML file. This does impact site builders or admins on production. The recommended approach would be to make these site building changes locally and then export them. Urgent changes can be made on production, but we also want to make sure that we do not overrides those configuration changes when we re-import on deploy.

Branching

We use git branching to avoid merge conflicts as we work on separate features. Our hosting provider, Pantheon, allows us to spin up environments for review when it comes to these branches. Branches are merged into master (dev) and then deployed upstream.

Upstream (Pantheon) Deployments

Merging to Master

We approach code changes, feature requests, and bug reports using Drupal.org. Once an issue has been assigned to a developer or site builder a separate branch of code is created for them to work on this. They can do testing/validation using a multi-dev environment on Pantheon.

Once a code change has been approved to be merged, please consult the team before merging to master. Once merged, you will want to use your local Drush aliases to run the database update scripts (if applicable) and to import configuration into the dev environment. This could look like:

drush @ddi.dev updb -y && drush @ddi.dev cim -y

Again, the -y parameter is optional if you want to manually review and confirm each process of the drush command.

Deploying to Test/Prod

After a certain interval, we will then deploy code changes from development to the test and stage environments. Note: Please remember (site builders, et al.) to make sure that production configuration changes are then pushed via configuration management yaml files into git. Similarly to the development deploy, we want to make sure that we run database updates (if applicable) and then import the configuration from code.

Test (Staging)

drush @ddi.test updb -y && drush @ddi.test cim -y

Prod (Production)

drush @ddi.prod updb -y && drush @ddi.prod cim -y

Join our mailing list!

* indicates required