Moving configuration and deployment

A Drupal site is code, configuration and content. Code is moved through Git and Composer. Configuration — content types, fields, views, role permissions, module settings — is kept in the database, so to move it you export it to files. Content stays on the production site.

The sync folder

The path to the folder with configuration files is set in the site settings file:

// web/sites/default/settings.php
$settings['config_sync_directory'] = '../config/sync';

The path is relative to the web folder, so the files end up in site/config/sync — outside the site root, unreachable from a browser. The line is added to the end of the file; if the setting is already there, replace its value.

Exporting

vendor/bin/drush config:export

The short form is drush cex. Hundreds of YAML files appear in config/sync: system.site.yml with the site name, node.type.article.yml with the Article type, blog.settings.yml with the settings of your module. The folder is added to the repository.

Importing

On another copy of the site, after getting the files from the repository, run:

vendor/bin/drush config:import

The short form is drush cim. Drush shows the list of differences — what will be created, changed and deleted — and after confirmation brings the site configuration in line with the files.

The drush config:status command shows the differences without changing anything.

The workflow

On your computer you configure the site in the panel and write code.
You export the configuration: drush cex.
You push the code and the config/sync folder to the repository.
On the server you pull the changes and import the configuration: drush cim.

Settings are not changed in the panel on the production server: the next configuration import would overwrite them.

Deployment steps

After every code update on the server, run:

git pull
composer install --no-dev --optimize-autoloader
vendor/bin/drush updatedb -y
vendor/bin/drush config:import -y
vendor/bin/drush cache:rebuild

Command	What it does
`git pull`	Gets your code and configuration files
`composer install --no-dev`	Installs core and modules of the same versions you have
`drush updatedb`	Applies database updates — the subject of the next lesson
`drush config:import`	Imports the configuration
`drush cache:rebuild`	Rebuilds the cache

The order matters: database updates first, then configuration, the cache last. The drush deploy command runs the last three steps itself and in the right sequence.

Server settings

Data that differs between the developer's computer and the server is not committed. It is set in the server's settings.php, read from environment variables:

// web/sites/default/settings.php
$settings['trusted_host_patterns'] = ['^example\.com$', '^www\.example\.com$'];
 
$databases['default']['default'] = [
    'driver' => 'mysql',
    'database' => getenv('DB_NAME'),
    'username' => getenv('DB_USER'),
    'password' => getenv('DB_PASSWORD'),
    'host' => 'localhost',
];

trusted_host_patterns lists the domains the site is allowed to open on. The web server points at the web folder, and the web/sites/default/files folder is made writable for it. In the panel, error display is switched off and aggregation of CSS and JavaScript files is switched on.

Common mistake

Never move the database from the developer's computer to the production server: you would overwrite the nodes and users created on the site. Content lives on the production site and is copied only downwards — from the server to the developer. Only code and configuration go up.

Thanks for reading!