web-dev-qa-db-ja.com

自動展開のためのDrushコマンドの順序？

次のDrushコマンドはどの順序で実行する必要がありますか？

  • config-import
  • 更新されたb
  • エンティティの更新

また、field_delete_data *テーブルが存在するため、エンティティの更新が失敗することがよくあります。自動展開の一部として削除するにはどうすればよいですか？

8drushdeployment
5
Paul Canning

updbとcimを入れ替えます。

  1. updbを確認して、hook_update_N()が最初に実行され、エンティティの更新が提供されるか、フィールドが削除されます（これは、 cim）またはモジュールを無効にするプログラムでpriorto更新された設定をインポートします。これにより、設定の欠落が原因でcimエラーが発生するのを防ぎます（たとえば、同じ実行で_core.extension.yml_を介してモジュールが無効になることを知らない）。
  2. cimをクリックして、残りの構成をインポートします。

コメントで述べたように、entupはローカル開発中にのみ使用することをお勧めします。そうでない場合は、hook_update_N()を介して提供される更新でカバーする必要があります。

_drush entity-updates_は開発者ツールです。カスタムモジュールでエンティティ/フィールドの定義を変更すると、これをすばやく適用できます。

本番環境では、これは起こらないはずです。公式リリース間でモジュールを更新する場合、モジュールの更新コードでこれを処理する必要があります。

出典： drush entity-updatesの目的は何ですか？

これが私が最も満足しているルーチン全体です（注：最初にcrを実行すると、構成のインポート後に後続のエラーが防止される場合があります）。

_git pull
composer install --no-dev
drush cache:rebuild
drush -y state:set system.maintenance_mode 1
drush -y updatedb
drush -y config:import
drush cache:rebuild
drush -y core:cron
drush -y state:set system.maintenance_mode 0
drush cache:rebuild
_

これは、contribモジュールを完全に削除したい場合に2つのリリースを実行することも意味します。モジュールを無効にする最初のリリース。 Composerによって削除される2番目のリリース。

実際の連続リリースを可能にするには、現在のリリースのコミットSHA1をデプロイメントスクリプトに渡し、_git pull_をより正確なルーチンに置き換えます（ここで、_$1_はSHA1です）。

_# If not empty 1st argument passed to the script, do:
if [ -n "$1" ]; then
  git reset --hard "$1"
else
  git pull
fi
_

そうしないと、2つの新しいリリースを一度に、または短期間でプッシュしたときに、連続性が保証されません。その後、最初のリリースでトリガーされた_git pull_は、（2番目のリリースからの）最新の変更を単にプルします。代わりに、最初のリリースに含まれる変更のみをプルします。完全なサンプルリポジトリ _leymannx/drupal-circleci-behat_ を参照してください。

このgitスニペットのクレジットは CircleCI に送られます。これは彼らが彼らのコンテナでそれをしている方法です。

18
leymannx

コマンドのシーケンスは次のとおりです。

updatedb (which runs update hooks)
config-import

Entity-updatesは非推奨であるため実行したくありません。 https://www.drupal.org/node/3034742 を参照してください。代わりに、更新フック（hook_update_N）を使用して、データベーススキーマまたは必要な構成を適切に変更します。

コードが変更された後、updatedbがDrupalを起動する最初のコマンド実行であることが必須です。 https://www.drupal.org/project/commerce/issues/310055 これが行われない場合に発生する可能性がある問題についてのいくつかの解説。

配置スクリプトの例

これは、その背後に多くのレビューと議論があったが、それが出発点であると考える配備スクリプトの例です。あなたがしたいと思う調整があるでしょう。アーティファクトをデプロイしていることを前提としています（composerインストールはデプロイメントで実行されないことに注意してください）。

drush sset system.maintenance_mode TRUE
# Create a restore point by taking backups of anything that is not in the code repository: database, media, cache
# Checkout the code you are deploying
drush updb
drush cim sync -y || drush cim sync -y
drush cim sync -y
drush sset system.maintenance_mode FALSE
drush cr

この背後にある詳細な説明については、 https://www.bounteous.com/insights/2020/03/11/automate-drupal-deployments/ を参照してください。 Drushにデプロイコマンドを含めるためのPRである https://github.com/drush-ops/drush/pull/4359/ も参照してください。

上記のスクリプトは開始点であると述べましたが、そのスクリプト（または使用するデプロイスクリプト）に適用した方がよいと思われるいくつかのバリエーションを文書化しました： https：//www.bounteous。 com/insights/2020/03/12/automated-drupal-deployment-and-rollback-recipes /

0
josephdpurcell