The answer is... generally run updates first. Whether to import or export the configuration afterwards depends on who updated the contrib code base.
You are updating the contrib code base
If you are updating the contrib code base, run the database updates and then export the configuration, as updates tend to alter the configuration storage data which needs to be commited into the version control system:
- Pull changes from the repository
drush cim
to import your colleagues' configuration changescomposer update
to update the contrib code basedrush updb
to update the Drupal databasedrush cex
to export potential configuration changes after the update- Commit changes into the repository
tl;dr
git pull \
&& drush cim -y \
&& composer update \
&& drush updb -y \
&& drush cex -y \
&& git commit
Someone else updated the contrib code base
If you are on the receiving end of an update (someone else updated the contrib code base), or you are in fact a deployment script and not a developer, run the database updates and then import the configuration:
- Pull changes from the repository
composer install
to synchronize your contrib code base with the remotedrush updb
to update the Drupal databasedrush cim
to import your colleagues' configuration changes
tl;dr
git pull \
&& composer install \
&& drush updb -y \
&& drush cim -y
Alternatively use the new drush deploy command
The need to standardize Drupal deployment has led to the following command:
drush deploy
This does roughly the same, but the docs state that if more control over the deployment process is needed, the atomic commands need to be used like in the example above.
Comments
The title seems to be somewhat misleading. What you’re correctly pointing out is the difference in procedure when you are applying contrib updates to a codebase as opposed to when somebody else made those changes (at which point there doesn’t need to be any difference between a deployment that does or does not contain contrib updates; run updates, import config). Your central point is that the update process may apply changes to the configuration. When one understands that, the rest makes perfect sense.
Thanks for your input! I find the title on point, but the first sentence underneath the title may be slightly misleading - it is now fixed.
Yes, true. Much better.
In the "You are updating the contrib code base" part, you should add the step where you're locally modify your code, config or composer.json.
Note that the "Someone else updated the contrib code base" part could also be used for deploy.
Another chapter about dealing with rebasing and merge conflicts could be really helpful.
Please read the title of this post - a simple question is being answered here and non of your suggestions fit as part of the answer.
This is wrong.
https://www.drush.org/latest/deploycommand/
https://drupal.stackexchange.com/questions/254407/order-of-drush-comman…
@Si The deploy command fails to cover many use cases. It may work well for you, but take a look at the bottom of the doc you linked:
I updated the post to include information about the new drush deploy command.
Add new comment