it-swarm.com.de

Reihenfolge der Drush-Befehle für die automatisierte Bereitstellung?

In welcher Reihenfolge sollten die folgenden Drush-Befehle ausgeführt werden?

  • konfigurationsimport
  • aktualisiertb
  • entity-Updates

Außerdem sehe ich, dass Entitätsaktualisierungen aufgrund vorhandener field_delete_data * -Tabellen häufig fehlschlagen. Wie kann ich sie im Rahmen meiner automatisierten Bereitstellung löschen?

5
Paul Canning

Ich würde updb und cim tauschen.

  1. updb um sicherzustellen, dass hook_update_N() zuerst ausgeführt wird , um Entitätsaktualisierungen bereitzustellen oder Felder zu löschen (was nicht über möglich ist) cim) oder um Module programmgesteuert vor zu deaktivieren Importieren der aktualisierten Konfiguration. Dies verhindert, dass cim aufgrund fehlender Konfiguration auf Fehler stößt (ohne beispielsweise zu wissen, dass ein Modul im selben Lauf über core.extension.yml Deaktiviert wird).
  2. cim, um die verbleibende Konfiguration zu importieren.

Wie in den Kommentaren erwähnt, sollte entup nur während der lokalen Entwicklung verwendet werden und sollte ansonsten durch Aktualisierungen abgedeckt werden, die über hook_update_N() bereitgestellt werden.

drush entity-updates Ist ein Entwicklertool. Wenn Sie Entitäts-/Felddefinitionen in Ihrem benutzerdefinierten Modul ändern, können Sie dies schnell anwenden.

In der Produktion sollte dies nicht passieren. Wenn Sie ein Modul zwischen offiziellen Releases aktualisieren, sollte der Update-Code im Modul dies behandeln.

Quelle: Was ist der Zweck von Drush-Entity-Updates?


Hier ist die gesamte Routine, mit der ich am glücklichsten bin (Hinweis: Das Ausführen von cr am Anfang und nach dem Konfigurationsimport kann nachfolgende Fehler verhindern):

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

Dies bedeutet auch, dass Sie zwei Releases ausführen müssen, wenn Sie ein Contrib-Modul vollständig entfernen möchten. Erste Version zum Deaktivieren des Moduls. Zweite Version, um es von Composer entfernen zu lassen.


Um echte aufeinanderfolgende Releases zu ermöglichen, möchten Sie möglicherweise das Commit SHA1 der aktuellen Version an das Bereitstellungsskript übergeben und dann git pull Durch eine genauere Routine ersetzen (wobei $1 Das SHA1 ist):

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

Andernfalls kann die Konsekutivität nicht garantiert werden, wenn Sie zwei neue Releases gleichzeitig oder innerhalb kurzer Zeit pushen. Da dann die erste Version ausgelöst wird git pull, Werden einfach die neuesten Änderungen (aus der zweiten Version) abgerufen, wobei stattdessen nur die Änderungen abgerufen werden sollten, die in der ersten Version enthalten sind. Siehe das vollständige Beispiel-Repo leymannx/drupal-circleci-behat .

Das Guthaben für dieses git - Snippet geht an CircleCI . So machen sie es in ihren Containern.

18
leymannx

Die Reihenfolge der Befehle sollte sein:

updatedb (which runs update hooks)
config-import

Sie möchten keine Entitätsaktualisierungen ausführen, da diese veraltet sind (siehe https://www.drupal.org/node/3034742 . Verlassen Sie sich stattdessen auf Update-Hooks (hook_update_N), um das Datenbankschema oder die erforderlichen Konfigurationen ordnungsgemäß zu ändern.

Es ist unbedingt erforderlich, dass updateedb der erste Befehlslauf ist, der Drupal nach dem Ändern des Codes startet. Sie können https://www.drupal.org/project/commerce/issues) sehen/310055 für einige Kommentare dazu, welche Probleme auftreten können, wenn dies nicht getan wird.

Beispiel für ein Bereitstellungsskript

Hier ist ein Beispiel für ein Bereitstellungsskript, das viel überprüft und diskutiert wurde, aber es als Ausgangspunkt betrachtet. Es ist wahrscheinlich, dass Sie Anpassungen vornehmen möchten. Es wird davon ausgegangen, dass Sie ein Artefakt bereitstellen (beachten Sie, dass composer wird bei der Bereitstellung nicht ausgeführt).

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

Eine ausführlichere Erklärung finden Sie unter https://www.bounteous.com/insights/2020/03/11/automate-drupal-deployments/ . Siehe auch https://github.com/drush-ops/drush/pull/4359/ Dies ist eine PR, die einen Bereitstellungsbefehl in Drush enthält.

Ich habe erwähnt, dass das obige Skript ein Ausgangspunkt ist. Ich habe einige Variationen dokumentiert, die Sie möglicherweise auf dieses Skript (oder jedes von Ihnen verwendete Bereitstellungsskript) anwenden möchten, die hilfreich sein könnten: https: //www.bounteous. com/Insights/2020/03/12/automatisierte Drupal-Bereitstellung und Rollback-Rezepte /

0
josephdpurcell