Ergebnis 1 bis 11 von 11

Thema: Kontinuierlicher Deployment Prozess, Weiterentwicklung und Versionsverwaltung

  1. #1
    Contao-Nutzer
    Registriert seit
    09.09.2009.
    Beiträge
    26

    Standard 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?
    Geändert von neverdying (14.02.2015 um 16:14 Uhr) Grund: Einheitliche Formatierung, Community Aspekt herausstellen, Liquibase

  2. #2
    Contao-Nutzer
    Registriert seit
    03.09.2009.
    Ort
    Baunatal
    Beiträge
    122
    Partner-ID
    6087

    Standard

    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.

  3. #3
    Contao-Nutzer
    Registriert seit
    09.09.2009.
    Beiträge
    26

    Standard

    Zitat Zitat von Wusch Beitrag anzeigen
    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?

  4. #4
    Contao-Nutzer Avatar von chibineko
    Registriert seit
    02.06.2011.
    Beiträge
    120
    Partner-ID
    6306

    Standard

    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.
    Don't assume anything is possible or impossible until you've asked the people who will be doing the work. (Picard management tip)

  5. #5
    Contao-Nutzer
    Registriert seit
    09.09.2009.
    Beiträge
    26

    Standard

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

  6. #6
    Contao-Nutzer
    Registriert seit
    09.09.2009.
    Beiträge
    26

    Standard

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

  7. #7
    Administratorin Avatar von lucina
    Registriert seit
    19.06.2009.
    Ort
    Kiel (DE)
    Beiträge
    7.376
    Partner-ID
    152
    User beschenken
    Wunschliste
    Contao-Projekt unterstützen

    Support Contao

    Standard

    Tut es doch ...????

  8. #8
    Contao-Nutzer
    Registriert seit
    09.09.2009.
    Beiträge
    26

    Standard

    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.

  9. #9
    Contao-Urgestein
    Registriert seit
    07.07.2009.
    Beiträge
    4.107

    Standard

    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

  10. #10
    Contao-Nutzer
    Registriert seit
    09.09.2009.
    Beiträge
    26

    Standard

    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"
        },

  11. #11
    Contao-Nutzer Avatar von bytehead
    Registriert seit
    03.08.2009.
    Ort
    Luzern, Schweiz
    Beiträge
    105
    Partner-ID
    7707

    Standard

    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
    1up AG » Ihr Realisationspartner für Projekte und Erweiterungen mit Contao und Symfony!

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •