Was ist der vorgeschlagene Workflow für die Migration (CMI) der Konfiguration von dev -> stage -> production?

41

Wir hatten vor ein paar Monaten ein Drupalcamp und jemand fragte nach der Verwaltung von Bereitstellungen mit dem neuen Konfigurationssystem (CMI). Ein möglicher idealer Workflow besteht darin, die Konfiguration in der Versionskontrolle zu belassen und dennoch die Konfiguration zwischen Teammitgliedern migrieren zu können.

Das Beste, was wir im Raum herausfinden konnten (teilweise basierend auf der Präsentation auf der DrupalCon Portland), war:

Weisen Sie die Versionskontrolle an, das aktive Konfigurationsverzeichnis zu ignorieren.
Kopieren Sie die gesamte Konfiguration in das Staging-Verzeichnis und übernehmen Sie die Versionskontrolle.

Verwenden Sie settings.php, um das Active / Staging-Verzeichnis zwischen den beiden Umgebungen umzukehren. Obwohl das Herausfinden eines Bereitstellungs-Workflows von einem Server zum nächsten komplex, aber machbar war, ist der vorgeschlagene Workflow von mehreren lokalen Umgebungen (dh mehreren Entwicklern) zu dev (oder untereinander) ein mögliches Problem für jedes Teammitglied würde die gleiche oder eine ähnliche Umgebung teilen, also wie kommen Änderungen auf dem Computer eines Teamkollegen zustande?

migration 8 version-control

— Btmash
quelle

5

Ich stimme den gegenwärtigen engen Abstimmungen nicht wirklich zu. Da CMI ein Schwerpunkt für Drupal 8 ist, können wir hier einige gute Antworten finden.

— mpdonadio

3

Einverstanden, das ist die sehr gute Frage. Ich glaube, die kritische Aufgabe drupal.org/node/1703168 befasst sich mit diesem und anderen Themen und ist noch nicht vollständig gelöst. Eine Antwort hier könnte helfen, dieses Problem voranzutreiben.

— Berdir

Ich entschuldige mich, wenn meine Frage gegenüber der CMI-Initiative negativ ausgefallen ist (was überhaupt nicht meine Absicht war). Ich habe die Frage aktualisiert, damit sie neutraler klingt.

— Btmash

2

Ich wollte fast sagen "Haben Sie Features ausprobiert". Vielleicht sollte der "D8" in den Fragentitel gehen? Das "8" -Tag ist etwas unsichtbar.

— donquixote

1

Der Titel wurde überarbeitet, sodass die Frage sowohl nach Tag als auch nach Titel

— angezeigt werden kann

19

Nach einem kurzen Gespräch mit den CMI-Betreuern ist die Diskussion darüber, was der beste Ansatz ist, noch nicht abgeschlossen. Im Folgenden wird jedoch erläutert, was im Moment am sinnvollsten ist.

Wenn Sie versuchen, es vorerst knapp zu halten, wird versucht, anhand von Fragen zu erweitern, bzw. wenn das Problem, auf das verwiesen wird, mit einer offiziellen Antwort behoben ist.

Also, zuerst die Fakten ...

Wie bereits erwähnt, gibt es das Active- und Staging-Verzeichnis. Active wird vollständig von Drupal verwaltet. Änderungen, die direkt (direkt oder indirekt durch Wechsel zu einem anderen Standort) vorgenommen werden, werden nicht unterstützt.
In Staging sucht Drupal nach zu importierenden Konfigurationen und kümmert sich sonst nicht darum.
Der Importvorgang ist wichtig. Konfigurationsänderungen können sich auf bestimmte Weise auf eine Site auswirken und müssen auf Gültigkeit überprüft werden. Sie können den Feldtyp eines Textfelds nicht in einen Entitätsverweis ändern, der einfach nicht funktioniert.
Der Konfigurationsimport muss immer für alle Konfigurationen ausgeführt werden. Sie können nicht eine einzelne Ansicht oder einen einzelnen Knotentyp importieren. Es wurde versucht, aber der Versuch, mit Abhängigkeiten umzugehen, entfernte / benannte und so weiter, führte zu einem sehr komplizierten System und es funktionierte nicht.
Die einzige Möglichkeit, die Standardkonfiguration erneut zu installieren, besteht darin, das betreffende Modul erneut zu installieren. Das bedeutet, dass zuerst versucht wird , alle Konfigurationen (wie Felder) zu entfernen . Das ist also keine Option. Manuelle, spezifische Änderungen der Update-Funktionen sind möglich, aber meiner Meinung nach zu langwierig.
Wie im Funktionsmodul beschrieben, wird der Schwerpunkt auf wiederverwendbaren Funktionen und nicht auf kontinuierlichen Konfigurationsbereitstellungen liegen. Dafür wurde es in erster Linie entwickelt.

Angesichts dessen empfiehlt es sich derzeit, das Staging-Verzeichnis in die Versionskontrolle einzubeziehen. Jeder Entwickler hat dann die volle Kontrolle darüber, was er dort ablegt, indem er entweder das gesamte Active Directory oder nur eine bestimmte Konfigurationsdatei kopiert. Die Staging-Verzeichnisänderungen werden dann festgeschrieben, an die Produktion weitergeleitet und der Konfigurationsimport wird ausgeführt (in der Benutzeroberfläche oder mit drush).

— Berdir
quelle

Das Staging-Verzeichnis in der Versionskontrolle bekomme ich diesen Teil. Die anderen Teile sind das, was mein Verstand zu verarbeiten versucht. Wenn also jemand eine Änderung vornimmt, kopiert er seine Änderungen in das Staging-Verzeichnis und schreibt es fest. Danach erhalten die anderen Entwickler / der nächste Server die Änderungen und synchronisieren sie mit dem Active Directory. Und spülen und wiederholen Sie diese Schritte für alle anderen Serverketten (Staging, Produktion usw.). Und es wird immer gestuft, sodass kein Verzeichniswechsel mehr stattfindet. Wäre das richtig?

— BTMASH

Ja. Es darf keine Verzeichnisumschaltung geben. Jede Konfigurationsänderung muss den Importvorgang durchlaufen, da Sie sonst möglicherweise eine beschädigte Site haben. Zum Beispiel ist die Liste der Module auch Konfiguration. Die Bereitstellung bedeutet, dass Module installiert / deinstalliert werden müssen (Hinweis: Dies funktioniert noch nicht, es gibt jedoch ein Problem, das behoben werden kann).

— Berdir

Ok, jetzt noch mehr Fragen (aufgeteilt in 2 Kommentare) :) Zuerst erwähnen Sie, dass Module Konfiguration sind. Auch wenn ein Modul zu einem Repo hinzugefügt und nicht aktiviert / deaktiviert wird, muss es installiert / deinstalliert werden, um dort zu sitzen.

— Btmash

Und die Folge: (A) Gibt es einen Mechanismus zum Kopieren von Änderungen aus dem aktiven Verzeichnis -> Staging (um das Wechseln in das Konfigurationsverzeichnis für diese Komponenten zu vereinfachen - möglicherweise eine Möglichkeit, bestimmte Variablen auszuwählen)? (B) Wird das Staging-Verzeichnis geleert, nachdem die Änderungen aus dem Staging synchronisiert wurden -> aktiv? (B1) Wenn ja, ist dann die Strategie vom Standpunkt der Entwickler, dieses Verzeichnis vor einem Git-Pull zurückzusetzen? (B2) Wenn nicht, ist es dann richtig anzunehmen, dass während der Ausführung von Staging-> Active Sync keine Auswirkungen auf die Konfiguration auftreten sollten, die sich nicht geändert hat?

— BTMASH

Der Installationsstatus des Moduls ist Konfiguration. Nicht das Modul selbst :) Das ist, was Sie bereitstellen. a) Es gibt eine Benutzeroberfläche zum Herunterladen einer tar.gz des aktiven Verzeichnisses, eine zum Hochladen der tar.gz in das Staging-Verzeichnis und eine zum eigentlichen Importieren mit Übersicht und Vergleich der Änderungen. B) Ich glaube, dass es jetzt geleert ist, aber ich gehe davon aus, dass Sie das mit git leicht rückgängig machen können. Nicht sicher, leicht zu überprüfen. Das ganze Zeug ist steckbar, es könnte also eine etwas andere Implementierung geben, die nicht gelöscht wird. B2) Ich verstehe das nicht, aber ich denke ja.

— Berdir

4

Great hat bisher geantwortet. Danke euch allen!

Wir haben kürzlich ein Drupal 8-Projekt gestartet und den folgenden Workflow implementiert.

Wir haben drei Ordner aktiv, Staging und Export. Entwickler geben ihre Daten für den Export aus. Ich möchte es nicht auf der Bühne lassen. Ich denke, es ist einfacher, damit zu arbeiten, wenn die freigegebene Konfiguration nicht direkt im Staging-Ordner gespeichert ist. Es ist nur ein Einfall, dass ich keine harten Fakten darüber habe ...

Unsere aktuelle Drupal 8-Projektvorlage ist auf github verfügbar. Ich habe auch einige praktische Drush-Befehle geschrieben, um den Devleoper-Workflow zu beschleunigen. Es ist kein manuelles Kopieren vom aktiven in den Export erforderlich.

Projektvorlage: https://github.com/webflo/d8-project-template
Zusätzliche Drush-Befehle: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— webflo
quelle

1

Soweit stimme ich diesem Ansatz zu. Ich habe alle Funktionen aus den Links in diesem Beitrag zu den Befehlen Drush config-export und config-import hinzugefügt. Ich hoffe, dass andere mich und @florian bei der Erforschung dieser 3-Verzeichnis-Lösung unterstützen.

— Moshe Weitzman

Wie gehen Sie mit der sites/default/files/config_HASHConfig - Ordner einen Hash - Suffix, zB config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— therobyouknow

@therobyouknow Es ist möglich, den Speicherort dieser Ordner zu überschreiben. Suchen Sie einfach nach "Speicherort der Site-Konfigurationsdateien". in settings.php verwende ich das folgende schnipsel. Dies bedeutet, dass die Konfiguration außerhalb des Drupals-Stammverzeichnisses gespeichert wird. $ config_directories = array ('active' => '../config/active', 'staging' => '../config/staging',);

— Webflo

Danke @webflo Ich habe das gesehen. Was wäre der Vorteil, wenn Sie eine Codebasis und eine Konfiguration getrennt verwalten würden? Ich denke, diese Trennung ist ein wenig künstlich, da sowohl Code als auch Config (in Yaml) das Verhalten bestimmen und voneinander abhängig sind. In Drupal 7 wurde die Konfiguration im Code (oder von Git nachverfolgbar) mit dem Modul "Features" durchgeführt, wobei ein Modul für jede bestimmte Konfiguration erstellt wurde, die im Code nachverfolgt werden musste. In Drupal 8 gibt es Features 3.x, die meines Wissens dasselbe tun, aber YAML zum Speichern der Konfiguration verwenden, und die generierten Module sind nicht vom Features-Modul abhängig.

— Therobyouknow

Ich denke du hast mich falsch verstanden, das Konfigurationsverzeichnis ist immer noch in Git, aber meine Drupal-Seite befindet sich nicht im Git-Repo-Stammverzeichnis. Die Seite ist gespeichert / web. / Config und / web sind also auf der gleichen Ebene.

— Webflo

2

Ich habe dies noch nicht ausprobiert, aber mein Plan ist es, ein benutzerdefiniertes Modul zu erstellen, das "Standard" -Konfigurationsdateien enthält, die nur die Konfiguration enthalten, die mir wichtig ist. Ich glaube, dass andere Module Configs enthalten können, die andere Module überschreiben. (Wenn nicht, sollte dies möglich gemacht werden).

Ich denke du musst den config Ordner in Ruhe lassen. Ignoriere es. Es wird bei der Installation automatisch aus allen Konfigurationsdateien der einzelnen Module generiert. Der Weg ist lang und zufällig. Wenn Sie all das in einem Repo aufbewahren würden, würden Sie ein separates Repo benötigen und Tonnen von nicht benötigten Standard-Konfigurationsdateien mit sich führen.

Das Einfügen von config in ein benutzerdefiniertes Modul macht es zu einem Teil Ihrer Hauptcodebasis.

Der Bereitstellungsprozess wäre:

Git ziehen oder was auch immer, um neue Dateien zu bekommen.
Löschen Sie die Caches.
Standardkonfiguration zurücksetzen. (Aus den Dateien Ihres benutzerdefinierten Moduls)

Sie können benutzerdefinierte Module (mit eigener Konfiguration) für jede Umgebung erstellen, wenn Sie möchten.

— Jonpugh
quelle

Das klingt nach Funktionen, nicht wahr? Oder gibt es einen signifikanten Unterschied, den ich vermisse?

— Letharion

Es ist ein interessanter Ansatz und ich mag die Idee. Einer der größten Vorteile, die im Rahmen der CMI-Initiative erwähnt wurden, ist jedoch die Möglichkeit, die Konfiguration aus den Konfigurationsverzeichnissen zu verschieben. Und aus dem, was ich sehe, können Sie in der settings.php-Datei bestimmen, wo sich die Active / Staging-Verzeichnisse befinden (dh sie müssen keine automatisch generierten Pfade sein). Daher denke ich, dass ein Workflow mit der aktuellen Konfiguration möglich sein sollte, ohne dass ein Feature erstellt werden muss, wie oben von @Letharion erwähnt.

— BTMASH

2

Hinweis: Ich weiß zu schätzen, dass dies in Bezug auf die Frage keine im engeren Sinne zutreffende Antwort ist, aber ich habe sie trotzdem hierher gestellt und werde sie überarbeiten und bearbeiten / löschen, sobald Features eine 8.x-Version und der Staub hat etwas mehr angesiedelt. Dies war einfach zu groß für einen Kommentar und ich wollte meine £ 0.02 in bekommen :-)

Als großer Fan von Features würde ich vorschlagen, die D8-Inkarnation des Features- Moduls im Auge zu behalten .

Aus der Projektseite entnommen

Für Drupal 8 ist die 3.x-Version von Features für die Integration in das neue Konfigurationsmanagementsystem geplant. Wenn Sie lediglich eine einfache Standortkonfiguration exportieren müssen, sollte anstelle von Features das D8-Konfigurationsverwaltungssystem verwendet werden. Sie werden Features in D8 verwenden, um gebündelte Funktionen zu exportieren (z. B. ein "Fotogalerie-Feature").

Die Art , wie ich irgendwie es sehe , ist , dass diese Idee macht es einfacher für Entwickler - Teams an die Arbeit auf kleinere Teile einer Website. Ich werde noch nicht auf einen Workflow eingehen, da es immer noch zu viele unbekannte Variablen gibt, aber ich kann nicht sehen, dass er sich stark von einer aktuellen Bereitstellungsprozedur für Features unterscheidet.

Ich kann nicht anders als zu denken, CMI ist großartig. Die meisten meiner Websites werden jedoch immer noch Features-Module enthalten (wenn auch eine geringere Menge, da nicht JEDER Inhaltstyp, jede Berechtigung usw. exportiert werden muss).

— Chapabu
quelle

Obwohl ich damit einverstanden bin, dass Features ihre Rolle geringfügig ändern und (hoffentlich) das Tool zum Bündeln von Konfigurationskomponenten (wie die von Ihnen erwähnte Fotogalerie-Funktion) sein werden, wird die Konfiguration (soweit ich das verstehe) weiterhin über Active verwaltet Konfigurationsverzeichnis. So können Features eine bestimmte Komponente lösen, aber wie der Konfigurationsverzeichnis-Workflow über Umgebungen hinweg verwaltet wird, ist das eigentliche Problem. Die Bereitstellungsprozedur unterscheidet sich geringfügig von der Bereitstellungsprozedur für die aktuellen Features, da sich die Activestore-Daten in der Datenbank befinden und der Datenspeicher Dateien enthält.

— BTMASH

... beinhaltet das Bereitstellungsverfahren für d7-Features das Speichern von Daten in der Datenbank und des Datenspeichers in Dateien. Wir wechseln zu Dateien und müssen nur sicherstellen, wie sich dies auf eine Verschiebung des Workflows auswirkt.

— BTMASH

Beachten Sie, dass für Features das Konzept von Active und Datastore / Staging in Wirklichkeit nicht gilt. Oder zumindest nicht konsistent, es hängt alles von dem spezifischen Hook / Ding ab, mit dem es sich integriert. Standardansichten leben im Code. Änderungen sind beispielsweise sofort aktiv (abgesehen vom Zwischenspeichern). Es gibt keinen kontrollierten Bereitstellungsprozess mit Funktionen. Dies war immer eines der Hauptprobleme bei der Verwendung von Funktionen für Bereitstellungen.

— Berdir

Du hast recht. Ich weiß nicht, wie ich das Konfigurationsmodul für D7 mit Features verwechselt habe, aber ich habe es getan.

— BTMASH