Contao-Projekt in Git mit DB ablegen... Best practise?

[Kronos]

Hallo zusammen,

ich würde gerne meine Contao-Projekte inkl. MySQL-DB in Git ablegen.
Wie macht ihr das? Welche Erfahrungen könnt ihr mir mitteilen?

Sichert ihr ALLES aus dem Contao-Verzeichnis oder nur /files, /templates?
Wenn ich nun zusätzlich Module installiere, müsste eig. auch /system mitgesichert werden, oder?

Habt ihr pro Projekt ein Script, welches das Contao-Verzeichnis und die DB-generiert und committed oder macht ihr das manuell?

Danke und viele Grüße,
Tobi

[the_scrat]

Wieso in Git? Dafür ist Git nicht gedacht!

Leg dir lieber ein paar scripte an die die Installation komplett oder in Teilen sichert, ebenso die DB und das Backup dann an einen externen Ort (owncloud, externe HDD etc.) verschiebt.

[BugBuster]

Dann hoffentlich in einem privat Git Projekt, sonst kann jeder deine Login Daten sehen in den Konfigs. (Sorry, hier dachte ich an GitHub und nicht GIT)
Contao 3.x oder 4.x?
Da gäbe es aus meiner Sicht auch noch Unterschiede. Klar ist es in beiden möglich einfach alles zu sichern. In Contao 4 wäre das, sofern man mit Composer auf Kommandozeile umgehen kann, gar nicht nötig.
Wobei das derzeit nur Theorie bei mir ist, probiert habe ich es noch nicht.

Wie hattest du das vor? Deine ganze Contao Installation lokal zur verwalten als GIT und dann ab und zu ein "git push" ?

Prinzipiell halte ich GIT als Backup Medium nicht so sinnig.

[Spooky]

Ich denke ihm geht es nur um das kollaborative entwickeln in Contao - inkl. Datenbank.

[the_scrat]

Ich denke ihm geht es nur um das kollaborative entwickeln in Contao - inkl. Datenbank.

Dann sollte er es auch so formulieren ;-) Für mich liest es sich aber mehr wie eine Art "Backup" in Git. Denn aus welchem Grund sollte man dann /files oder /templates sichern?
Vielleicht klärt er es ja noch auf.

[Spooky]

Denn aus welchem Grund sollte man dann /files oder /templates sichern?

Wenn du eine Website für einen Kunden entwickelst, werden ja auch dort dafür relevante Dateien abgelegt.

Und selbst wenn du nur alleine entwickelst, willst du deinen Stand ja evt. in ein Git Repository pushen - eben als "Backup" und wegen der Versionierung, damit man ggf. auf einen früheren Stand zurückgreifen kann.

[the_scrat]

Ok, das ist ein Argument. Wäre mir trotzdem zu umständlich :-) Bei Dateien geht es ja noch, aber die DB ständig in GIT zu pushen?! Dann doch lieber nen Script was halt alle n-Stunden nen dump erzeugt, fertig

[Spooky]

aber die DB ständig in GIT zu pushen?!

Dann hast du auch automatisch den Stand der DB versioniert und kannst ggf. darauf zurückgreifen.

[PaddySD]

Ich gestehe es ehrlich, auf die Idee bin ich bislang noch gar nicht gekommen...

Wenn man sich das aber so durch denkt... DB als *.sql sichern und in einem eigenen Verzeichnis als Datei mit rein in git. Die Sicherung an sich über script und cron.

Sollte doch so gehen, oder hab ich was übersehen?

[Kronos]

Wenn du eine Website für einen Kunden entwickelst, werden ja auch dort dafür relevante Dateien abgelegt.

Und selbst wenn du nur alleine entwickelst, willst du deinen Stand ja evt. in ein Git Repository pushen - eben als "Backup" und wegen der Versionierung, damit man ggf. auf einen früheren Stand zurückgreifen kann.

Korrekt!!
Warum sonst sollte ich denn git nehmen - deshalb verstehe ich die anderen Meinungen nicht so ganz.
Ich lege die Daten ja auch nicht in ein öffentliches gitlab sondern auf meinem lokalen Server.

Wie macht ihr das?

[Kronos]

Ich gestehe es ehrlich, auf die Idee bin ich bislang noch gar nicht gekommen...

Wenn man sich das aber so durch denkt... DB als *.sql sichern und in einem eigenen Verzeichnis als Datei mit rein in git. Die Sicherung an sich über script und cron.

Sollte doch so gehen, oder hab ich was übersehen?

Das wäre ja meine Idee...
Immer auf einen vorherigen - funktionierenden und ggf. zufriedenen Stand zurückgreifen, falls man sich verhaut.
Daher: git

Über ein Script die DB als .sql sichern wäre wohl die bessere Variante.
Aber wie mit dem Contao Verzeichnis verfahren?

Bei jedem Aufruf der Website ändert sich ja das Contao Verzeichnis, in dem iwelche Cache Dateien abgelegt werden.
Daher machen ja bestimmte Verzeichnisse wenig sinn.

Es gäbe dann quasi pro Projekt ein eigenes Skript, das die .sql erzeugt.

[Spooky]

Ich mache es genau so wie du . Aber mit zentralem, lokalen MySQL Server. Jeder checkt den Code lokal aus, benutzt aber die selbe Datenbank, damit man gleichzeitig an der Struktur der Website (Themes, Layouts, Inhalte, Module, etc.) arbeiten kann. Der SQL dump wird nach eigenem ermessen gemacht, könnte man aber auch automatisieren.

Aufpassen muss man nur, dass nicht jemand vom Entwickler Team unabsichtlich etwas aus der Datenbank dropped, wenn man innerhalb von Contao ein Datenbank Update durchführt und so vielleicht gerade die Backend Arbeit von jemand anderen der letzten x Minuten zu nichte macht .

Wie das andere machen weiß ich nicht, aber dieser Thread soll ja zum Austausch dienen. Es gab aber auch schon in der Vergangenheit ein oder zwei Threads dazu.

[BugBuster]

Bei jedem Aufruf der Website ändert sich ja das Contao Verzeichnis, in dem iwelche Cache Dateien abgelegt werden.
Daher machen ja bestimmte Verzeichnisse wenig sinn.

Dann schließe diese aus mittels Angaben in .gitignore

[Spooky]

z.B.:

# OS
.DS_Store
Thumbs.db

# IDEs
.buildpath
.project
.settings/
.build/
.idea/
nbproject/

# Contao
/composer/vendor/
/composer/composer.phar
/composer/composer.out
/composer/composer.pid
/composer/cache/
/contao/update.phar.php
/assets/css/*
/assets/images/*/*
/assets/js/*
/share/*.xml
/system/cache/*
/system/cron/cron.txt
/system/logs/*
/system/tmp/*
/vendor/

# See contao/core#7576
!/assets/css/index.html
!/assets/images/*/index.html
!/assets/js/index.html

Mit dieser .gitignore muss dann bei einem pull

composer install

im /composer und im Root Ordner ausgeführt werden, damit die Abhängigkeiten installiert werden.

[lindesbs]

Wenn Du keine Erweiterungen entwickelst ist es relativ einfach. per .gitignore alles verbieten ausser /files, /templates,/system/config/ und /composer/composer.json
Und dann git den Hook pre-commit um die DB vor dem commit mit in das Dateisystem zu nehmen (myssqldump).

https://git-scm.com/book/en/v2/Custo...-Git-Git-Hooks.

somit bleibt nur noch das adden und commiten und taggen.
Mit diesen Daten kannst du dann jederzeit das System neu aufziehen.


Beim Restore bzw. checkout brauchst Du dann nur noch den entsprechenden Tag raussuchen und fertig. Im post-checkout Hook die DB wieder restaurieren.

[cmichael]

In modx gibt's Gitify. Das ist ein kleines aber sehr feines Tool, um Datenbankänderungen als .YAML file abzulegen und um solche .YAML Files wieder direkt in die DB zu spielen. So wird es möglich bei größeren Datenbanken nur die Änderungen hin und her zu spielen. So wird es auch möglich ID Konflikte (zwischen Produktion und Entwicklung) manuell aufzuösen, da .YAML gut lesbar ist. Ich suche so was gerade auch für Contao - für größere Projekt (kollaborativ) sehr praktisch.

[Spooky]

Wenn du etwas gfunden hast, lass es uns wissen

[ph!L]

Hallo zusammen,

da dieses Thema ein wenig ohne Best Practice ausgekommen ist, hier noch mal meine (etwas abgewandelte) Fragestellung:

Wie arbeitet Ihr kollaborativ zusammen, wenn man nicht physisch am gleichen Ort sitzt (= keinen lokalen MySQL Server aufsetzen kann)?

Alle files über git zu verwawalten und auszutauschen ist ja soweit logisch. Aber die DB besteht eben nicht aus einzelnen Files, die man pushen und pullen kann?

Wir hatten dafür mal eine DB auf dem Webserver (auf dem wir die Preview für den Kunden auch zeigen), aber da hat man durch die Latenz natürlich riesige Wartezeiten bei jedem Refresh.
Gibt es da irgendetwas besseres?

Tausend Dank,

Philipp

[Patric]

Würde mich auch interessieren, hat da jetzt schon jemand eine Lösung?

[MrLumbergh]

Würde mich auch interessieren, hat da jetzt schon jemand eine Lösung?

Mich auch!

[ph!L]

Ich habe leider noch keine Lösung gefunden, außer dass inhaltliche Dinge auf einer Web-Datenbank erledigt werden, die dann regelmäßig von den Kollegen gedumpt und lokal eingespielt wird.

[Patric]

Falls es noch jemanden interessieren sollte, wir haben über das Thema einen Blogbeitrag verfasst. Vielleicht hilft es ja dem ein oder anderen weiter
http://www.ingenious-design.de/blogr...-workflow.html

[ihkwdiopk]

Falls es noch jemanden interessieren sollte, wir haben über das Thema einen Blogbeitrag verfasst. Vielleicht hilft es ja dem ein oder anderen weiter
http://www.ingenious-design.de/blogr...-workflow.html

Super Beitrag - der lässt keine Fragen offen.

[Webbaumeister]

Neue URL des Artikels:

https://www.ingenious-design.de/blog...ontao-workflow