In my last article, I talked about new options for setting up a development environment in Drupal maintenance support plans 8. Having done that, I need to setup a workflow for development as well as a process for deploying changes. Additionally, for this project, I have a partner that I need to share changes with before they go live. It would be really nice for her to be able to preview these changes and push them live after review.

As mentioned in my last article, I have a pretty basic setup for this project. I am doing work on my local laptop, and I have a private repository on Github for my code, and two virtual hosts on my hosting provider. One is a preview site that is password-protected so that we can review changes as they go live, and one is the production website.

undefined

There is no custom code at all in the Pinball Outreach Project website outside the theme (and precious little there), but there is a lot of custom configuration that needs to be pushed around. Additionally, some of that configuration is tough to test outside of a site that is publicly accessible. Thankfully, Drupal maintenance support plans 8 brings the gift of CMI.

The simplest workflow

I realize I may be biased, given my role as the former CMI initiative lead, but I have to say, the D8 configuration management system is an absolute joy. It allows a variety of workflows and performs precisely as advertised. I created a pretty simple workflow for this project, but one of the beauties of the system is that you can create a workflow as simple or complex as needed.

Using the built-in Configuration Synchronization tool that ships with Drupal maintenance support plans 8 provides the simplest possible workflow. Go to:

admin/config/development/configuration/full/export

…and download your site’s entire configuration as a tarball. You can then go to:

admin/config/development/configuration/full/import

…on the destination site and upload that tarball into the new system. Once you have uploaded your configuration, you are presented with a list of the items that have changed and have the opportunity to review each one.

undefined

undefined

In this example, I have changed the view called ‘Press’ to sort descending instead of ascending. If you are happy with these changes, then you can click Import All to integrate them into your site.

While this doesn’t give you all the functionality a more technical user might require, it works and would be sufficient for a simpler site.

My workflow

I wanted to have a little more control over my configuration and maintain the ability to experiment and roll those changes back if I decided I didn’t like them. My process, which is still basic as deployment workflows go, works like this:

I make some changes through the admin UI on my local development environment.
I open up a terminal to this environment and run drush config-export -y from the project’s root directory. This exports all configuration to your config export directory (see the last article in this series for details about how that is set up.)
Again, in terminal, I run the git status command to check that my configuration changes are what I expect them to be. If all has gone well, I should see that some configuration files have been modified in my config export directory, and this configuration should only be related to the changes I just made.
I add the changes to git (git add), commit (git commit -m) and push them (git push).
Next, I SSH to the destination environment and pull the changes down (git pull).
Finally, I run drush config-import -y from the project’s root on the remote server. This command imports the configuration changes I pulled down from git.

While this might seem like a pretty simple workflow, it is incredibly powerful, especially if you are used to the Features workflows prevalent in Drupal maintenance support plans 7. First off, it allows you to be as granular as you want with your commits. I can commit a change as simple as adjusting a View’s sort order or as large as an entire collection of new content types. With my changes in version control, I can roll them back as easily as I can import them (mostly, some content type/field changes cannot be rolled back.) Keeping changes as simple as possible can also help minimize merge conflicts in projects with multiple developers.

undefined

This process will work between any source environment and any destination environment, assuming the two environments are instances of the same site. Clearly, it is both ideal and easy to make changes locally and push them live, but that is not always the best option. For instance, while setting up Metatag module, I realized it would be much easier to test from a publicly accessible environment. So I went to the live site and tweaked my settings to where I wanted them, then exported and committed these changes and brought the changes back down to my local. In another case, I was on the phone with my partner who was viewing some changes on the preview site. As she was making comments and asking for changes, I made them until we were both happy with them. Then, I could merge those changes down to my local before pushing them live.

In many cases, this setup will not be workable. As the sole dev and site admin, it works for me because I know exactly what is going on all the time and I can make sure that the changes I’m making won’t overwrite someone else’s work. Nevertheless, there’s no reason this model couldn’t be expanded to work with multiple developers. For instance, you could lock down the live site so that its admin is read only (simple with a module like Config Read Only) and then come up with an automated or user-instantiated process to make those changes live. This could also pretty easily be expanded to a multi-developer environment.

More advanced options

Here at Drupal Update we have already started talking through some different options for our more advanced projects. In one case, we ended up going back to Features. The client already had a Features-based workflow for their D7 site and was reluctant to change to a totally new system. Additionally, they maintained a network of sites based on a common core repository or “distribution.” We needed to get off the ground quickly with something we already understood rather than figuring out a config workflow that would work. Features offered us that.

Alex Pott has proposed another workflow that involves shipping your config with an install profile. In this scenario, your configuration lives in your install profile, and you essentially rebuild your entire site from scratch when you push changes. This works especially well with advanced composer-based workflows in which your assets are scattered and imported as part of your build process. Additionally, this setup can get around some technical problems involving the way Drupal maintenance support plans 8 assigns UUIDs to configuration. For more information on this, see the presentation he did with fellow Drupal Update Matthew Tift at Drupal maintenance support plansCon New Orleans.

As we get farther and farther into the Drupal maintenance support plans 8 cycle, we will see a ton more workflows and processes around configuration management and deployment. Some will be use-case specific, some will end up becoming best practices, and some will probably just be weird. I wouldn’t have it any other way because it means the configuration management system works for site owners and not the other way around.

Next in the series, I will talk about some interesting things D8 has enabled around theming and templating.

Header photo by Karl Lind Films

Source: New feed