Kontinuierlicher Deployment Prozess, Weiterentwicklung und Versionsverwaltung

Einleitung in die Thematik:
Mich beschäftigt der kontinuierliche Deployment Prozess einer Contao Installation.
Ich laufe in die Situation, dass eine bestehende Installation weiterentwickelt wird und sich hierdurch
der Quellcode sowie die Datenbank ändert. Die Datenbank ändert sich jedoch auch durch aktive Arbeit der Redakteure im Live System.
Zu dieser Situation würde ich gerne Erfahrungswerte aus der Community sammeln.

Ich beschreibe mal meine Prozesse:
Eine bestehende Installation wird aktiv von Redakteuren gepflegt, die Inhalte der Datenbank haben eine hohe Änderungsrate.
Module, Templates oder Code werden nur vom Entwickler verändert.

Die eigentliche Entwicklungsumgebung ist eine lokale Vagrant Box.
Zwischen Entwicklung und Live steht ein Staging System mit identischer System Architektur.

Ich halte das Projekt in einem Git Repository und nutze Git ebenfalls als Deploy-Tool.

Hierzu eine kleine Nebenfrage:
Was haltet ihr alles in der VCS? Beispiel von .gitignore Files würden mich sehr interessieren.

Ich nutze den Git Workflow Gitflow.
Der Prozess sieht im wesentlichen so aus:

• Aktive Entwicklung in Feature Branches
• Merge des Feature zurück in den Develop Branch nach abgeschlossener QA
• Nach Abschluss der Entwicklungsphase wird der Develop Branch auf dem Staging System ausgecheckt, es erfolgt erneute QA
• Nach Abschluss der QA wird vom aktuellen Stand des Develop Branches, nach eventuellen Bugfixes, der nächste Release Branch gezogen
• Live gehen: neuen Release Branch auf der Live Maschine auschecken

Nun der Teil der mich aktuell beschäftigt:
Der letzte Schritt kann Änderungen an der Datenbank beinhalten. Wenn z.B. ein Modul installiert wurde, dass die DB aktualisiert.
Inhaltliche Konflikte sollten eigentlich per Prozess-Design nicht vorkommen, da der eigentliche Content nicht vom Entwickler angefasst wird.

Um nun beim Deployment nicht alles an Redaktions-Arbeit seit meinem letzten Release zu überschreiben, möchte ich eine Art Synchronization
duchführen. Zuerst hole ich mir einen Diff von der Live DB, fahre diesen Patch gegen die Dev DB. An dieser Stelle sollte die Redaktion kurz
geblockt werden um die DB nicht weiter zu verändern.
Nun erstelle ich einen neuen Diff von Dev gegen Live DB.
Zusammen mit dem Auschecken des neuen Release Branches auf der Live Maschine, würde ich letzteren Patch auf die DB anwenden.
Die Arbeit an den Datenbanken könnte mit einem Tool wie Liquibase erzielt werden.

Ziel ist es am Ende einen Prozess zu haben der mit einem CI Server wie z.B. Jenkins automatisiert werden kann.
Also Deploy auf Stage, Sync der Datenbanken, Live Deployment, Rollback.

Ich denke, dass die Contao Community von einem solchen Prozess profitieren kann.
Gerade Teams die an solchen Projekten in größeren Kontexten arbeiten sind eine interessante Zielgruppe.

Gibt es zu dieser Thematik Erfahrungswerte?

Für ein Projekt mit mehreren Standorten haben wir einen Jenkins-Server im Einsatz der auf Änderungen im Git Master Branch reagiert und diese auf die Standorte verteilt.
Falls es Änderungen an der DB gibt, spielen wir die über eine runonce bzw. über die Aktualisierung der Erweiterung ein.

Schön wäre es natürlich den letzten Schritt auch zu automatisieren. Also Contao geht in den Wartungsmodus, Daten werden eingespielt, Datenbank ggf. angepasst und der Wartungsmodus wird wieder beendet. Da wir aber nur 1 mal pro Monat Updates einspielen, ist das ganze noch überschaubar.

Zitat:

---

Zitat von Wusch

Falls es Änderungen an der DB gibt, spielen wir die über eine runonce bzw. über die Aktualisierung der Erweiterung ein.

---

Könntest Du diesen Prozess, bzw. diese zwei Prozesse, etwas detaillierter erläutern?

Unter "runonce" verstehe ich eine PHP Datei in einem Modul die einmal ausgeführt wird und anschließend gelöcht wird. Von hier führt ihr dann SQL Statements aus. Wie realisiert ihr einen Rollback im worst-case?

Moin,

bei uns ist es meist so, dass die Kunden nicht pflegen, bzw. wir eine Preview bereitstellen, wenn die Kunden doch pflegen wollen. Hier können die Kunden dann vorab alle Änderungen vornehmen und diese prüfen. Anschließend synchronisieren wir alle Daten mit der Erweiterung SyncCto bzw. lassen dies auch von dem Kunden selber durchführen. (Sofern der Kunden sich dies zutraut.)

Genauso gehen wir auch mit der Weiterentwicklung vor. Wir schließen dann alle Accounts vom Kunden, synchronisieren die Daten auf unsere Entwicklung und fangen an zu arbeiten. Wenn alle Arbeiten erledigt wurden, synchronisieren wir die Änderungen wieder auf die Liveseite. Hier kommt es maximal zu ~1 Minute Downtime. Wenn überhaupt.

Durch das Tool können auch unsere PM und Azubis Seiten hochladen.

Das Tool kann leider dabei keine diffs anzeigen von den Dateien, macht aber eine Prüfung der MD5 Hashes von Dateien um Änderungen zu finden. Bei der Datenbank wir der Timestamp der letzten Änderung benutzt, um zu prüfen, ob es Änderungen an einer Tabelle gibt. Mit der Pro Version ist er allerdings möglich ein Diff von der tl_page, tl_article und tl_content zu bekommen.

SyncCto sieht in der Tat nach dem richtigen Werkzeug.
Ich versuche mal meinen Prozess damit abzubilden und werde hier meine Erfahrungen posten.

SyncCto ist leider raus, bis es Contao >=3.2 unterstützt.

Tut es doch ...????

Nachtrag zu meinem letzten Post:
Die v2.5.3 funktioniert in der Tat nicht mit Contao >= 3.2 (getestet auf 3.4.4) und weist auch während der Synchronisierung darauf hin. Direkt zu Beginn erscheint eine Nachricht, dass die neue Ordnerstruktur von Contao 3.2 noch nicht unterstützt wird.

In meinem zweiten Test habe ich v2.7.0-beta1 installiert und diese Version läuft auf Contao 3.4.4 sauber.

Ich finde es etwas eigenartig das du die Version 2.5.3 verwendest obwohl es noch knapp 10 Versionen danach gibt.

https://packagist.org/packages/menatwork/synccto

Der Composer client zeigt mir alle anderen Versionen >v2.5.3 & <2.7.0-beta1 als inkompatibel an.

Auszug aus meiner aktuellen composer.json

Code:

---

    "require": {
        "components/bootstrap": ">=3.3.2.0,<3.4-dev",
        "contao-bootstrap/bundle": ">=1.0.0.0-RC1,<1.1-dev@RC",
        "contao-community-alliance/composer-client": "~0.12",
        "contao-legacy/backupdb": ">=3.2.2.9004,<3.3-dev",
        "menatwork/synccto": ">=2.7.0.0-beta1,<2.8-dev@beta",
        "netzmacht/contao-theme-plus": "5.1.x-dev"
    },

---

Also syncCto läuft bei mir auf einer 3.2.19 mit folgendem require:

Code:

---

"menatwork/synccto": ">=2.6.2.0,<2.7-dev",

---

Grüsse
bytehead