Von Develop nach Production - Workflow

[treudoof]

Hallo zusammen,

vielleicht ist das schonmal aufgetaucht oder auch dem ein oder anderen aufgefallen. Von meiner Seite aus ist es eine Art Frage, aber vielleicht auch eine Art "Traumvorstellung", zu der ich gern die Meinung erfahrener REDAXO-Entwickler hören wollen würde

Ausgangssituation:

Nach div. Vorgesprächen ist der Auftrag endlich in der Tasche. Es wird geplant, es wird designed, es werden Pflichen/-Lastenhefte erstellt, alles ist unterzeichnet, und jetzt geht es an die Umsetzung in REDAXO.

Soll/Ist-Situation

Im nachfolgenden möchte ich gerne meine "Traumvorstellung" in grün schreiben und meine Gedanken/Probleme/Hinweise dazu einfach regulär darunter, dass es leserlicher und verständlicher ist.

Mehrere Entwickler, die parallel an diesem Projekt arbeiten, sollen (zumindest file-bezogen) lokal entwickeln können.

Im Prinzip dank Versionierung erstmal kein Problem auf dem aktuellen Stand zu bleiben. Die (eine) Datenbank bleibt im Firmen-Netz bzw. auf einem zentralen Server. Meine Bedenken: Es wird ja schon die ein oder andere Konfiguration gesetzt, die umgebungsabhänging ist. Dabei fällt mir z.b. ein: IncludePath, DocumentRoot, Domain und vermutlich noch einige mehr. "Out of the box" vermutlich also nicht trivial lösbar.

Initialer (angepasster) REDAXO Stand nach dem ersten Clone. Idealerweise habe ich ein "eigenes" Repository in die aktuelle REDAXO Version liegt, die ggf. etwas an die eigenen Bedürfnisse angepasst ist. Gut vorstellen könnte ich mir auch, dass dort bereits das ein oder andere (Standard)-Modul/Template/Addon bereits drin liegt, welches ggf. nur noch installiert werden muss.

Hierbei stellen sich mir folgende Fragen/Probleme/Gedanken:

Wie können wir die REDAXO Core Version up2date halten? Da wir selbst bitbucket und nicht github nutzen, fällt der klassische "Fork" weg. Idee: Ich lege ein neues Repository bei bitbucket an, und lege ein neues remote "upstream" zu github an, welches mir REDAXO selbst ggf. aktuell hält wenn ich das pullen möchte.

Addons: Theoretisch spricht ja dann eigentlich nichts (mehr) dagegen die einzelnen Addons per submodule in dieses Respository einzubinden. Wie sieht es bei Projekten aus wenn die mal 1 Jahr alt sind, das Addon aber deutlich weiterentwickelt wurde? Einfach via git pull aktualisieren? Oder so laufen lassen wie es ist?

Templates/Module: Wenn man das developer3 Addon verwendet, wäre es nicht denkbar durch die neue Struktur auch alle Templates und Module in einer Basisversion zu versionieren?

Entwicklung von eigenen Addons/Modulen. Diese sollen natürlich pro Addon/Modul in einem eigenen Repository zu finden sein.

Zunächst einmal: Muss/sollte man Addons/Module die man entwickelt veröffentlichen auf REDAXO? Von meiner Seite aus spricht hier nichts dagegen. Wir geben uns relativ viel Mühe, Module recht flexibel, optisch ansprechend und auch inhaltlich sinnvoll zu "entwickeln". Das ganze mit der Community zu teilen, ist also vermutlich für alle ein Mehrwert.

Wie geht man diesbezüglich nun am besten vor? Einfach im aktuellen Projekt entwickeln, git Repository erstellen und das ganze als submodule einbinden? So kann man von jedem Projekt theoretisch aus einfach weiterentwickeln, und das ganze wieder hochpushen, da wo es hingehört.

Deployment

Hier gibt es dann (wenn der vorherige Workflow realisiert werden könnte), eigentlich keinerlei Probleme mehr. Auf dem Live-System ein clone - und das war's.

git - Submodule ganz allgemein

Zugegebenermaßen können wir alle mit git eigentlich ganz gut umgehen, hängen aber wissenstechnisch bei submodulen etwas hinterher. Wie sie technisch funktionieren ist klar, dennoch finden wir zu einer Problematik die wir haben, keine Antwort. Vielleicht hat daher hier jemand zu diesem OT eine kurze einfache Antwort parat.

Cloned man z.b. das aktuelle REDAXO Repository (mit entsprechenden submodulen), hängt jedes submodule auf dem HEAD des jeweiligen submodules. Wieso ist das so? Wieso zeigt das nicht auf den master? Gesetz dem Fall ich will an diesem submodule weiterentwickeln (direkt in diesem Projekt), müsste ich ja erst auf den entsprechenden branch auschecken, um weiterarbeiten, committen und pushen zu können. Denn solange das auf den HEAD zeigt, kann ich ja nichts dran machen (commit/push). Oder denke ich komplett falsch, und man entwickeln nicht direkt im submodule selbst?


So - das war's eigentlich erstmal. An diejenigen die es interessiert und die sich (danke schonmal!) die Mühe gemacht haben, meinen Sermon hier zu lesen, würde ich mich super freuen, wenn hier die ein oder andere konstruktive Meinung bei rumkommt. Wir sind jederzeit für neues natürlich offen und vorallem neue Perspektiven aufgezeigt zu bekommen.

[jdlx]

Mehrere Entwickler, die parallel an diesem Projekt arbeiten, sollen (zumindest file-bezogen) lokal entwickeln können.

Im Prinzip dank Versionierung erstmal kein Problem auf dem aktuellen Stand zu bleiben. Die (eine) Datenbank bleibt im Firmen-Netz bzw. auf einem zentralen Server. Meine Bedenken: Es wird ja schon die ein oder andere Konfiguration gesetzt, die umgebungsabhänging ist. Dabei fällt mir z.b. ein: IncludePath, DocumentRoot, Domain und vermutlich noch einige mehr. "Out of the box" vermutlich also nicht trivial lösbar.

Pfade sind das geringste prob.. bzw. eigentlich keines (es sei denn etwas ist statisch gecoded). Absolute params wie SERVER,SERVERNAME,DB, .. lassen sich z.b. per host switch in der master lösen, kein prob.

Was aber ein ersthaftes prob ist:

1. mehrere Entwickler.. heißt mindestens permanentes pushen/pullen und grundsätzliche Vorsicht bzw. Absprachen wer grad was macht.. das ist in der Praxis nämlich de facto nicht so einfach.
2. die DB.. in vielerlei Hinsicht das größte und am schwersten zu lösende Problem. Zwar kann man mit developer einen kritischen Bereich davon lösen, sprich templates/module/.. aber bezügl. der "Inhalte" (article(slices),files,metainfos..) steht man halt ziemlich im Regen. Eine site Entwicklung die ohne sukzessive Änderungen an diesen Daten auskommt dürfte ein Ausnahmefall sein. Ein live + staging Konzept hilft da auch nicht.. das prob liegt zwischen staging und devs.. zumindest wenn man es bidirektional für alle halten will. Man kann natürlich sagen alle DB Änderungen dürfen nur @ staging passieren, und laufen dann one way zurück zu den devs, aber die Praxis zeigt wie knifflig auch sowas ist.

Da wir selbst bitbucket und nicht github nutzen, fällt der klassische "Fork" weg. Idee: Ich lege ein neues Repository bei bitbucket an, und lege ein neues remote "upstream" zu github an, welches mir REDAXO selbst ggf. aktuell hält wenn ich das pullen möchte.

Du kannst problemlos redaxo als repo (auch privates) @ bitbucket importieren.. ist in 1 min. durch. Das original repo als remote dazunehmen, changes mergen/cherry-picken..

Addons: Theoretisch spricht ja dann eigentlich nichts (mehr) dagegen die einzelnen Addons per submodule in dieses Respository einzubinden. Wie sieht es bei Projekten aus wenn die mal 1 Jahr alt sind, das Addon aber deutlich weiterentwickelt wurde? Einfach via git pull aktualisieren? Oder so laufen lassen wie es ist?

Submodule.. sind so ne Sache, habt ihr ja schon bemerkt ;) Is durchaus machbar, aber auch einigermaßen Aufwand und mit Stolperfallen und wtf Momenten. Nested repos nehmen diesen Schmerz, aber da is halt Essig mit in einem Rutsch git clone -recursive oder so.. läßt sich aber wiederum per deployment scripten lösen. Irgendeinen Tod muß man sterben ;)
Was ein update per git pull angeht: im Prinzip klasse, bei rex4 Addons/Templates aber nicht ganz so easy/elegant, weil üblicherweise die settings innerhalb des Addons(repos) stehen.. siehe dazu meine Initiative zur Auslagerung der settings ala r5 auch (noch) bei r4.. http://www.redaxo.org/de/forum/addons-f ... 29-15.html .. denn ist das repo clean, reicht eben ein simples exec("git pull") aus PHP heraus und das wars.. ists nicht, wirds halt messy.

Templates/Module: Wenn man das developer3 Addon verwendet, wäre es nicht denkbar durch die neue Struktur auch alle Templates und Module in einer Basisversion zu versionieren?

Ja

Muss/sollte man Addons/Module die man entwickelt veröffentlichen auf REDAXO?

Wird gern gesehn zummindest.. ist aber halt Aufwand der mit der Zahl der items und der update Frequenz schnell zu viel wird. Es gibt ne API @ redaxo.org, aber dafür muß man sich halt auch erstmal post-commit hooks stricken. Ich weiß auch nicht wie da der aktuelle Stand ist und ob/wo sie dokumentiert ist.. -> Gregor fragen..

Deployment
Hier gibt es dann (wenn der vorherige Workflow realisiert werden könnte), eigentlich keinerlei Probleme mehr. Auf dem Live-System ein clone - und das war's.

Wenn man sich an die live/staging Konventionen hält sollte das zumindest relativ schmerzfrei sein, ja.

[treudoof]

Hi Jan,

vielen Dank für deine (wie immer) genommene Zeit und ausführliche Antwort. An vielen Stellen hast du mir vermutlich erstmal den Schubs in die richtige Richtung gegeben. Ich kann im Moment nur noch nicht soviel dazu sagen, werde mir aber in jedem Fall auf Basis deiner Aussagen mal etwas überlegen und sehen wie man da am besten auf einen grünen Zweig kommt. Würde das dementsprechend dann hier mal niederschreiben.

Apropos niederschreiben. Ist zwar ein grundlegend anderes Thema, aber bevor ich jetzt nur unnötigerweise was neues aufmache: Ich kann dir nicht mal sagen wieso ich das so empfinde, aber ich empfinde es so, dass die REDAXO.org Seite hier extrem unstruktiert ist in den einzelnen Unterseiten. Bzw. alles ist sehr zerpflückt; die Wiki erinnert mehr ein einzelne durcheinander gewürfelte Seiten. Infos hier zu finden ist eigtl (wenn man sich nicht auskennt) nahezu nicht möglich. Daher ganz direkt die Frage: Kann man euch da irgendwie unterstützen?

[jdlx]

werde mir aber in jedem Fall auf Basis deiner Aussagen mal etwas überlegen und sehen wie man da am besten auf einen grünen Zweig kommt.

Ergänzend noch der Hinweis auf folgenden thread allg., bzw. das hidden feature in firephp um DB Changes per autom. dump in einer Versionierung überhaupt mal sichtbar zu machen: http://www.redaxo.org/de/forum/allgemei ... ml#p106296

Nachtrag: ich bin in obiger Antwort (blind) davon ausgegangen, daß devs auch eigene/lokale Instanzen des Projekts bearbeiten.. geschieht alles "in house" und alle arbeiten direkt an staging, fallen ein paar Probleme weniger an, vor allem das leidigste: DB changes zwischen staging und devs..

[treudoof]

Du bist "blind" schon richtig davon ausgegangen. Zumindest was die Codebase betrifft. Datenbanktechnisch könnten alle die gleiche nutzen, zumindest war das der Plan, wenn da nichts dagegen spricht, denn dann würden - wie du sagtest - vllt das ein oder andere Problem wegfallen.

[treudoof]

Achja, dabei sind mir noch 2 kleinere Dinge gekommen, die du ja bestimmt adhoc beantworten kannst:

a) Ich denke ich kenn die Struktur des R4 relativ gut, macht es sich jetzt schon Sinn Gedanken zu R5 zu machen? Wenn nichts dagegen spricht würde ich zunächst gern auf R4 bleiben, insbesondere dann, wenn R5 noch einige Monate brauch bis es offiziell released wird.

b) Wenn ich aus dem R4 Repository clone und update - sollte ich das letzte Version-tag (hier 4.5) verwenden oder kann ich guten Gewissens immer den master aktuell halten?

vg
Stefan

[jdlx]

Wenn nichts dagegen spricht würde ich zunächst gern auf R4 bleiben, insbesondere dann, wenn R5 noch einige Monate brauch bis es offiziell released wird.

Ganz einfach: man setzte die Version ein, die den aktuellen Erfordernissen entspricht.. bezügl. des thread Themas: Strategien/Procedere werden ziemlich dieselben bleiben.. in r5 sind ein paar Themen besser gehandelt insfoern wirds nach dem Umstieg eher schmerzfreier.

b) Wenn ich aus dem R4 Repository clone und update - sollte ich das letzte Version-tag (hier 4.5) verwenden oder kann ich guten Gewissens immer den master aktuell halten?

Ich würde master nehmen.. sind ja primär bugfixes die committet werden, sprich die will man haben.

Noch ein Hinweis zur merge Strategie wenn man seinen eigenen clone von Redaxo vorhält: je weniger changes man im eigenen clon hat, desto problemloser sind merges.. bestenfalls so, daß man direkt die master mergen kann. Relativ nervig wird auch hier wieder das submodule Thema: hat man abweichende/andere submodule gibt es halt schnell Konflikte die man per Hand lösen muß (geht u.u. auch git seitig programmatisch, muß man sich aber auch erst schlau machen und umsetzen).
So oder so: man sollte den Aufwand nicht unterschätzen.. per se, aber vor allem im Hinblick auf merges.. der Aufwand z.b. dies hier https://github.com/gn2netwerk/redaxo4#readme zu maintainen ist nicht ohne.. und merges mache ich wg. den submodule Konflikten inzwischen eigentlich ausschließlich per cherry-picking.. der Weg des geringsten Schmerzes. ;)

[treudoof]

Ganz einfach: man setzte die Version ein, die den aktuellen Erfordernissen entspricht.. bezügl. des thread Themas: Strategien/Procedere werden ziemlich dieselben bleiben.. in r5 sind ein paar Themen besser gehandelt insfoern wirds nach dem Umstieg eher schmerzfreier.

Nun, die Frage bezog sich eher darauf, inwieweit mit einem Production Release zu rechnen ist, denn Erfordernisse hin oder her, ne alpha produktiv einzusetzen halte ich für fragwürdig.

So oder so: man sollte den Aufwand nicht unterschätzen.. per se, aber vor allem im Hinblick auf merges.. der Aufwand z.b. dies hier https://github.com/gn2netwerk/redaxo4#readme zu maintainen ist nicht ohne.. und merges mache ich wg. den submodule Konflikten inzwischen eigentlich ausschließlich per cherry-picking.. der Weg des geringsten Schmerzes.

Wenn ich ehrlich bin, macht mir das auch am meisten Sorgen. Das originale Repos hat ja bereits einige submodule drin, wenn ich jetzt auch das anfange mein eigenen Schuh zu machen, mit eigenen subs, n weiteres remote habe die wiederrum subs haben. Prost Mahlzeit. Ich geb dir zu 100% Recht, dass das nicht ohne ist - aber deswegen ja hier der Fred. Weil ich auf der "Ich habe die perfekte Lösung"-Lösungsuche bin - wobei ich merke, die gibt es vermutlich nicht. Wie du schon so schön sagtest.. "Einen Tod muss man vermutlich sterben..."

vg
Stefan

[jdlx]

..die Frage bezog sich eher darauf, inwieweit mit einem Production Release zu rechnen ist

Kann man höchstens interpolieren..

ne alpha produktiv einzusetzen halte ich für fragwürdig.

Klar.. aber selbst wenn der core stable ist, kommt zumindest noch ne Weile das Thema 3rd party Addons die man dafür benötigt dazu..

..wenn ich jetzt auch das anfange mein eigenen Schuh zu machen, mit eigenen subs, n weiteres remote habe die wiederrum subs haben. Prost Mahlzeit.

Yup.. würde ich die Nummer heute neu anfangen, würde ich glaub eher ein um das ein oder andere Addon gestriptes core rex ohne jegliche submodule nehmen, alles was dazu soll als eigenes unabhängiges repo, und das ganze per release/deployment script zusammenbacken.

Übrigens kann man hinsichtlich dev instanzen nochmal richtig weit ausholen und die Nummer mit vms (standartisierte server + der eigenen master installation) per vagrant/packer o.ä. abfeiern. Sehr ausgecheckt, aber halt auch nicht mal eben so zusammengeklickt. Evtl. sagt dazu jemand noch was..

[treudoof]

Yup.. würde ich die Nummer heute neu anfangen, würde ich glaub eher ein um das ein oder andere Addon gestriptes core rex ohne jegliche submodule nehmen, alles was dazu soll als eigenes unabhängiges repo, und das ganze per release/deployment script zusammenbacken.

Übrigens kann man hinsichtlich dev instanzen nochmal richtig weit ausholen und die Nummer mit vms (standartisierte server + der eigenen master installation) per vagrant/packer o.ä. abfeiern. Sehr ausgecheckt, aber halt auch nicht mal eben so zusammengeklickt. Evtl. sagt dazu jemand noch was..

Alternative wäre vielleicht composer? Muss ich mal genau drüber nachdenken. Ich bin zumindest soweit in meinen Gedanken angekommen, dass ich alles versuche "standalone" zu machen, das spart mir viel Arbeit. Sprich: Eigenes redaxo4 Repos, mit den entsprechenden Addons, ohne jegliche Submodules.

Grund: Wann nutze ich denn die Master-Installation? Eigentlich ja nur für neue Projekte. Wenn die abgeschlossen sind, wird man vermutlich ja eher selten bis gar nicht, dieses System dauerhaft mit den neuen Versionen aus der Master-Installation versorgen, weil diese Leistung ja letztlich sowieso nicht bezahlt wird. Und für neue Projekte hat man ja immer die aktuellste Version. Erscheinen neue Versionen von Addons, o.ä. kann man die ja auch durchaus manuell in der Master-Installation updaten. Denn ob ich mir da den Schuh anziehe, alles zu mergen und die Konflikte ständig aufzulösen, bin ich (fast) schneller wenn ich das manuell mache. Das sorgt unterm Strich zumindest für ein sauberes Repository. Die REDAXO Core Changes kann man dann ja per Cherry-Pick reinholen.

Ist natürlich alles noch sehr theoretisch, weil ich versuche meine Gedanken erstmal zu ordnen. Aber sowas wird sich in der Praxis schnell zeigen denk ich.

vg
Stefan