Deployment Lösung für Drupal 7 - ich kann nichts vernünftiges finden...

Genau das würde mich auch brennend interessieren, so gesehen eine Staging Plattform, das nach Updates, Weiterentwicklung mit dem aktuellen Stand von Usern und Nodes weiter gearbeitet werden kann.

Bisher ist mir das Feeds Modul bekannt (event. auch Features), habe mich aber noch nicht in die Struktur eingearbeitet da es mich nach der Installation erschlagen hat an Möglichkeiten.

Grüße Jenna

Das ist bei Drupal 7 auch alles noch nicht so einfach. Inhaltstypen kann man mittels bundel_copy übertragen. Views kann man exportieren und importieren, rules ebenso. Bei anderen Konfigurationen muß man die Arbeit auf der Live-Seite nochmal machen. Das ist alles noch nicht so befriedigend.
Bei Drupal 8 wird die Konfiguration in speziellen Dateien abgelegt, die man dann versionieren und auch problemlos von einem auf das andere System übertragen kann, ohne daß man sich um die Inhalte kümmern muß.

Es gibt verschiedene Ebenen.

1. Dateien, Module => Code
Alles was Code ist, sollte über ein Versionsverwaltungssystem laufen (git). Das bedeutet, du entwickelst und testest und lädst dann den Code hoch.

2. Inhalte, Konfigurationen => Datenbank
Runterladen der Datenbank von Live ist oft hilfreich, um mit tatsächlichen Inhalten zu arbeiten und zu entwickeln. Auf DEV solltest du keine Inhalte einpflegen, die du nachher auch auf live haben willst - da du hier testest und entwickelst und testest, macht das auch wenig Sinn. Live-Inhalte also immer auf Live erstellen. Bleiben die Konfigurationen (Einstellungen in der Drupal-Oberfläche die in der Datenbank gespeichert werden, alles mögliche wie z.B. Views, Inhaltstypen, und vieles mehr). Dafür gibt es das Features Modul und die zu diesem Kreis gehörenden Module.

3. Code und Datenbank
Beim Update von Modulen kommt es vor, das zusätzlich zum Code auch Datenbankänderungen anstehen. Dazu muss die update.php aufgerufen werden, die sich darum kümmert. Diese Funktionsollte also auch für selbst geschriebene Module verwendet werden.

Je nach Größe deines Projekts ist ein System mit DEV und LIVE vll. auch zu wenig, und es sollte zusätzlich noch die stage TEST geben. Dazu gibt es dann noch versch. Automatisierungstools. Drush ist hilfreich (sql-sync), vor allem mit den Drush Aliasen.

So, jetzt hast du zumindest ein paar Punkte für die weitere Recherche. Mit Drupal 8 soll es aber viele weitere Verbesserungen für diese Problemstellung geben.

Viel Erfolg.

Erstmal danke für die Antworten.

Also wenn ich das richtig verstehte, gibt es wohl für Drupal 7 noch keine vernünftige Lösung. Und erst durch die Trennung von Konfig und Inhalt mit Drupal 8 es eine brauchbare Lösung geben wird....

Zu den Lösunsansätzen

Ja genau so sehe ich das auch. Die Module sind nicht das große Problem.

Das herunterladen der LIVE-DB hat nur das Problem, dass ich nicht den kompletten Dump in meine DEV Umgebung einspielen kann. Ansonsten überschreibe ich mir ja auch z.B. die neuen Views oder CCK Felder, welche ich im DEV angelegt habe. Oder es müssen Module wieder aktiviert werden, etc etc.

Das Feature Modul scheint recht mächtig zu sein. Ehrlich gesagt, etwas zu mächtig für mich. Ich will eigentlich nur die aktuellen Inhalte von Live auf DEV bringen.

Ich habe gestern mal das Modul data_export_import getestet. Dort kann man Nodes, Taxonomien und User exportieren und dann wieder im DEV System importieren. So kann ich mir zumindest den DEV Stand, was Inhalt und User angeht, aktuell halten.

Soweit ich das gesehen habe (noch nicht ausprobiert) kann man die Exports auch per Rules (oder Cronjob) ansteuern. Die Export Dateien werden als Files auf dem System abgelegt und können dann, z.B. per Shell Script, auf den DEV Server verschoben und wieder im DEV System eingespielt werden. Also hier könnte man sich was recht brauchbare "basteln". Aber mal ehrlich, richtig gut ist was anderes, oder?

Man bekommt das mit Drupal schon sehr gut hin. Wie schon vorher geschrieben ist die Lösung, die Konfiguration aus der Datenbank in Code zu packen. Dazu sind das Features Modul und das Strongarm Modul das Mittel der Wahl. Wenn man das Deployment automatisieren möchte, verwendet man GIT, um den exportierten Features-Code zu versionieren und per Jenkins zu deployen (ohne das Kopieren und überschreiben der Datenbank den Code auf einen anderen Server zu transportieren). In Google gibt es dazu zahlreiche Blogpost.

Wenn ich das richtig verstehe geht es im Prinzip darum, die von der Community zwischen dem Zeitintervall "habe einen DB-Clone erstellt" und "spiele den DB-Clone evtl mit neuen Feldern zurück" erstellten neuen Einträge zu berücksichtigen.

Hierzu ein Gedankenspiel:
letzter erstellter node vor export in Testumgebung: id = 1;
3 Tage Entwicklung , dann node id auf der aktiven Seite = 3;

Auf der Entwicklungsseite neue Felder eingefügt und Inhalte generiert. Darunter node mit id = 2 UND / XOR neue Felder.

Wie sollte der merge ablaufen?

Via drush kann ich doch nur den cache auflösen. Aber ein merge von wegen "erhöhe den Eintrag der Testumgebung auf node id = 4 von node id =2"???

Ist das mit gegebenem Standardprogramm echt lösbar? Meiner Meinung nach müsste man da ein eigenständiges Skript schreiben, das die individuellen Belange je nach Veränderung berücksichtigt!

Lasse mich aber gerne eines besseren belehren!

Schönes Wochenende Euch allen, und bn auf Eure Antworten gespannt!

Eigentlich genau andersrum, die Idee (zumindest wie ich das gern hätte) wäre wie folgt:
Live Version mit 8 ContentTypes ( gleich 8 Hauptbereiche wie Autos, Boote etc.) mit z.B. jeweils 200 Nodes und dementsprechend vielen Benutzerkonten und Produkte / Commerce.

Nun stehen Updates an oder ich möchte Commerce weiter entwickeln, neue Rules oder Module testen, also alles was man ungern im Live Betrieb macht.
Ich erstelle heute ein Backup für die Dev und arbeite daran 7 Tage und alles läuft.

Nun möchte ich alle neu entstandenen Nodes und User aus den letzten 7 Tagen zusätzlich auf die neue Version ziehen um nicht alles händisch im Live Betrieb nachzubauen.

Neue Nodes auf der Dev müssen ja nicht entstehen, dafür reicht ja eine generelle Testnode auf unveröffentlicht, die man immer mitnimmt sowie ein Testuser um vorhandene ID, UID nicht durcheinander zu bringen. Oder hab ich was übersehen das es so nicht umsetzbar wäre?

Grüße Jenna

Ist es nicht irrelevant, hier von der Idee sprechend. Dann allgemeiner:

Entweder werden die nodes oder was auch immer auf der Testseite oder der Live Seite gemerged. Der Vorgang ist ja der gleiche. Meiner Meinung nach müsste die Seite kurz angehalten werden, ein dump gezogen werden, dieser dann gemerged werden auf der testseite, danach auf der live Seite eingespielt werden.

Die zentrale AUssage aber, die zu diskutieren wäre:

Kann es überhaupt ein skript geben, das alle Fälle abdeckt, und wenn ja wie? Meiner Meinung nach nicht. Gerade features ist für mich ein Modul, das zum Einsatz kommt wenn ich verschiedene Module brauche die gemeinsam einen speziellen Zweck erfüllen.

Drush kann meines Wissens nach auh keinen merge.