Upgrade Your Drupal Skills
We trained 1,000+ Drupal Developers over the last decade.
See Advanced Courses NAH, I know EnoughHow I upgrade Drupal 8 Sites with exported config and Composer
Over the years, as Drupal has evolved, the upgrade process has become a bit more involved; as with most web applications, Drupal's increasing complexity extends to deployment, and whether you end up running Drupal on a VPS, a bare metal server, in Docker containers, or in a Kubernetes cluster, you should formalize an update process to make sure upgrades are as close to non-events as possible.
Gone are the days (at least for most sites) where you could just download a 'tarball' (.tar.gz) from Drupal.org, expand it, then upload it via SFTP to a server and run Drupal's update.php. That workflow (and even a workflow like drush up
of old) might still work for some sites, but it is fragile and prone to cause issues whether you notice them or not. Plus if you're using Drush to do this, it's no longer supported in modern versions of Drush!
So without further ado, here is the process I've settled on for all the Drupal 8 sites I currently manage (note that I've converted all my non-Composer Drupal codebases to Composer at this point):
- Make sure you local codebase is up to date with what's currently in production (e.g.
git pull master
). - Reinstall your local site in your local environment so it is completely reset (e.g.
blt setup
ordrush site-install --existing-config
). I usually use a local environment like Drupal VM or a Docker Compose environment, so I can usually just log in and run one command to reinstall Drupal from scratch. - Make sure the local site is running well. Consider running
behat
and/orphpunit
tests to confirm they're working (if you have any). - Run
composer update
(orcomposer update [specific packages]
). - On your local site, run database updates (e.g.
drush updb -y
or go to/update.php
). _This is important because the next step—exporting config—can cause problems if you're dealing with an outdated schema. - Make sure the local site is still running well after updates complete. Run
behat
and/orphpunit
tests again (if you have any). - If everything passed muster, export your configuration (e.g.
drush cex -y
if using core configuration management,drush csex -y
if using Config Split). - (Optional but recommended for completeness) Reinstall the local site again, and run any tests again, to confirm the fresh install with the new config works perfectly.
- If everything looks good, it's time to commit all the changes to
composer.lock
and any other changed config files, and push it up tomaster
! - Run your normal deployment process to deploy the code to production.
All done!
That last step ("Run your normal deployment process") might be a little painful too, and I conveniently don't discuss it in this post. Don't worry, I'm working on a few future blog posts on that very topic!
For now, I'd encourage you to look into how Acquia BLT builds shippable 'build artifacts', as that's by far the most reliable way to ship your code to production if you care about stability! Note that for a few of my sites, I use a more simplistic "pull from master, run composer install
, and run drush updb -y
workflow for deployments. But that's for my smaller sites where I don't need any extra process and a few minutes' outage won't hurt!
About Drupal Sun
Drupal Sun is an Evolving Web project. It allows you to:
- Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
- Facet based on tags, author, or feed
- Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
- View the entire article text inline, or in the context of the site where it was created
See the blog post at Evolving Web