In this article, we are going to cover the Drupal 8 configuration lifecycle. We will start by making a simple configuration change in our local environment, then export the change to code, and eventually deploy it to different environments on Acquia Cloud.
This guide assumes Acquia’s ‘vcs’ directory exists, your site’s configuration was successfully exported and changes were committed and pushed to your Git repository. Please refer to Using the Acquia VCS directory and Configuration management for Drupal 8 for more information about Configuration Management on Acquia Cloud.
Additionally, knowledge of Drush config commands is strongly recommended as the guide makes heavy use of them. Also, we are assuming that multiple site aliases that correspond to each Acquia Cloud environment are setup properly (e.g.
Make changes locally
In Drupal 8, Views are configuration entities, which makes them a great candidate for Configuration Management workflow. Let’s start by adding a new field "Authored on" to the default "Content" view:
- Go to
- Add the "Authored on" views field and configure it as needed.
- Save the view.
Export changes to configuration directory
The modified "Content" view only resides in the "config" database table, which is also known as the "active" configuration store. In order to deploy those changes to other environments or share them with other developers, we need to export them to YAML files into Acquia Cloud's
vcs configuration directory. We will use Drush because it provides for very convenient export and import commands.
Export via Drush:
$ drush @sitename.local config-export vcs Differences of the active config to the export directory: Collection Config Operation views.view.content update The .yml files in your export directory (/../docroot/../config/default) will be deleted and replaced with the active config. (y/n)
Note that we export the configuration to the
vcs directory (in our example,
config/default) deliberately rather that Drupal's default
sync directory. This is because Acquia Cloud expects the former so that you can track configuration changes under version control. See Using the Acquia VCS directory for more details.
In this instance, only
views.view.content is being modified in the active datastore. Once you confirm replacing the existing configuration file, the view in the export directory will match the view in the active store (database). Before you push new code to the remote dev environment, make sure they reflect your desired changes:
$ git diff diff --git a/config/default/views.view.content.yml b/config/default/views.view.content.yml index c1976dd..6491f5b 100644 --- a/config/default/views.view.content.yml +++ b/config/default/views.view.content.yml @@ -355,6 +355,73 @@ display: hide_alter_empty: true destination: true plugin_id: entity_operations + created: + id: created + table: node_field_data + field: created + relationship: none + group_type: group + admin_label: '' + label: 'Authored on'
Deploy changes to the remote Dev environment
Now that changes have been exported to the config directory, we need to add them to the code repository in order to synchronize them effectively to Acquia Cloud environments.
Hint: the following git command could be issued after establishing an SSH connection to your dev environment. Alternatively, you could issue git commands from your local environment if Drush aliases are set up properly.
Note: for the sake of simplicity, we’ll assume commits are pushed to the
develop branch and it’s checked out in our Dev environment. Your workflow may vary, though. For example, it might be recommended to push code to a separate feature branch like
$ git checkout develop $ git add --all . && git commit -m "Add Authored on field to Content view" $ git push origin develop
Your Acquia Cloud dev environment should now have an updated
config directory. However,
/admin/content doesn't include the "Authored on" field we've just added in code. The reason why is changes need to be imported from the
config directory to the active configuration store. Importing changes can be accomplished either manually or by configuring your CI solution (e.g. Jenkins or Acquia Cloud CD) to trigger a config import upon pushing new commits to the code repository.
We recommend Drush to manually import changes from the
vcs config directory. Doing this will replace the "Content" views configuration in the database with the one we recently introduced in code:
$ drush @sitename.dev config-import vcs Collection Config Operation views.view.content update Import the listed configuration changes? (y/n):
Deploy changes to remaining environments
It’s time to merge our changes for testing on the stage environment.
Note: we assume that changes are merged into the
master branch for purpose of testing. Also, the Acquia Cloud stage environment is using code from the same branch.
On your local machine merge the
develop branch into the
master branch using the following Git commands:
$ git checkout master $ git merge develop $ git push origin master
Next, import changes to your staging environment
$ drush @sitename.test config-import vcs Collection Config Operation views.view.content update Import the listed configuration changes? (y/n):
admin/content and rebuild Drupal caches if necessary. By now, the staging environment should reflect changes we introduced locally.
After QA, you can then deploy changes to the prod environment by using the same technique.