Questions & Answers

[JoSt]

Hallo zusammen,

derzeit sind wir dabei mit Hilfe der DevTools (fs-cli) und GIT einen Entwicklunsprozess mit mehrern Entwicklern zu etablieren.

Derzeit verfolgen wir folgenden Ansatz:

• Wir haben eine dreistufige Systemlandschaft (Dev, Qa und Produktivsystem).
• Auf dem Dev-CMS-Server befindet sich ein zentrales Entwicklunsprojekt ("Dev-Master")
• Jeder Entwickler hat auf dem Dev-CMS außerdem ein eigenes Entwicklunsprojekt, in dem ausschließlich dieser Entwickler arbeitet.
• Jedes der Dev-Projekte hat einen eigenen Synchronisierungsordner, über den Ex/Importe des Templatestores mit Hilfe der DevTools abgewickelt werden.
• Jeder der Synchroniererungsordner ist außerdem die Basis für ein lokales GIT-Repositroy. Hierbei wird der .FirstSpirit ordner über .gitignore ignoriert.
• Diese lokalen GIT-Repositories sind mit einem zentralen Remote-Repository verbunden und sollen darüber synchronisiert werden
• Auch die CMS Projekte in Qa und Produktivsystem sollen über GIT/DevTools die Templateänderungen erhalten.

Bei Änderungen an bestehenden Templates können wir auf diese Weise die Änderungen bereits in das zentrale Entwicklunsprojekt transportieren, bei neuen Templates haben wir allerdings das Problem, dass diese nicht in andere Projekte importiert werden können, da die Informationen innerhalb des .FirstSpirit Ordners fehlen, der ja nicht über GIT synchronisiert werden soll. Beim Transport in andere Systemebenen (Qa/Prod) werden wir ebenfalls dieses Problem haben.

Hat vielleicht schon jemand die gleiche Problematik gehabt oder Lösungsansätze dazu?

Viele Grüße,

Johannes

[CVogel]

Hallo Johannes,

welche FirstSpirit-Version setzt ihr ein? Seit 5.2R14 gibt es nur noch einen zentralen .FirstSpirit-Ordner, der dann auch nicht synchronisiert werden soll. Die "Meta"-Informationen zu den FirstSpirit-Objekten befinden sich allerdings nicht im .FirstSpirit-Ordner sondern in den FS_-Dateien, die neben den fachlichen Dateien der FirstSpirit-Objekte liegen und somit ebenfalls ins Git eingecheckt werden.

Hast du denn ein konkretes Problem festgestellt?

Viele Grüße

Christian

[JoSt]

Hallo Christian,

dann liegt es bestimmt daran, dass wir noch folgende Files im .gitignore haben, da SIe Projektspezifische informationen (vorallem IDs) enthalten:

/.FirstSpirit/

**/FS_Info.txt

**/FS_References.txt

**/StoreElement.xml

Da wir git auch dazu verwenden wollen unsere Änderungen und Entwicklungen nachzuverfolgen. Wenn diese Files mit berücksichtigt werden, ist das fast nicht möglich. Da ja jedes Projekt zumindest eigene IDs verwendet, oder auch wenn verschiedene Sprachen vorhanden sind, wird beim Einchecken in das zentrale Repository nahezu überall eine Änderung erkannt. Was uns dabei interessiert sind ja allerdings nur die fachlich relevanten Änderungen und nicht irgendwelche technischen IDs.

Hat vielleicht jemand in diese RIchtung schon Erfahrungen gemacht?

Ist es auch wirklich unproblematisch die Files mit IDs/UUIDs bei einem Import des Templatestores von einem Quellprojekt in ein anderes Zielprojekt zu verwenden?

Viele Grüße,

Johannes

[CVogel]

Hallo Johannes,

die Dateien

**/FS_Info.txt

**/FS_References.txt

**/StoreElement.xml

MÜSSEN alle eingecheckt werden!

Bitte lest euch unbedingt die Dokumentation durch: „External Synchronization“​.

Wir sind sehr an Feedback interessiert und diskutieren jederzeit gerne eure Anforderungen aber ihr müsst die Funktion schon so einsetzen, wie sie von uns vorgesehen ist.

Da ja jedes Projekt zumindest eigene IDs verwendet, oder auch wenn verschiedene Sprachen vorhanden sind, wird beim Einchecken in das zentrale Repository nahezu überall eine Änderung erkannt.

In Entwicklungsprojekten sollte die Sprachmenge identisch sein. Welchen Grund gibt es, dass unterschiedliche Entwickler unterschiedliche Sprachen in ihren Projekten haben?

Projektspezifische IDs gibt es in den Export-Dateien nicht, daher gibt es auch die Änderungsproblematik nicht.

Habt ihr denn konkrete Probleme festgestellt?

Welche FirstSpirit-Version setzt ihr denn ein und welche Version des fs-cli?

Viele Grüße

Christian

[JoSt]

Hallo Christian,

unser Haupt-Entwicklungsprojekt ist gleichzeitig ein Paketmaster für Templates und Inhaltspakete. Es besitzt lediglich zwei technische Sprachkanäle (deutsch & englisch) die als Übersetzungsquelle für unterschiedliche Generierungssprachkanäle gedacht sind (die nur in den Slaveprojekten vorhanden sind und dort befüllt werden). Um neue Entwicklungen zu testen werden aber oft diese Generierungssprachkanäle gebraucht, daher gibt es bzgl. der Sprachen einen Unterschied zwischen den Entwickler-Projekten und dem Haupt-Entwicklungsprojekt.

Wir wollten die DevTools zunächst verwenden, um Unterschide im Templatestore zwischen den Haupt/Master-Projekten unserer Systemebenen Dev/Qa/Prod festzustellen und damit unsere Transporte zwischen diesen EBenen (per Content Transport Feature) zu unterstützen. Wir sind dabei so vorgegeangen:

Der Templatestore der drei Master-Projekte wurde per fs-cli exportiert und als GIT-Repository initialisiert sowie mit einem zentralen GIT Repository verbunden.

Jedes Projekt wurde in einen separaten Branch auf dem Remote GIT gepusht (dev/qa/master).

Der git diff zwischen zwei Branches zeigte die Unterschiede auf.

In diesem Zustand wurde für jedes Template ein Unterschied festgestellt, da die IDs unterschiedlich waren. Um dann auf dieser Basis eine sinnvolle Vergleichbarkeit zu erreichen haben wir die .gitignore wie oben erwähnt erweitert.

Evtl. sind wir auch falsch an die Sache herangegangen? Wenn ja, wie müsste man das Vorgehen anpassen?

Unser finales Ziel ist wie erwähnt ein Transportwesen das ohne die Notwendigkeit zur manuellen Erzeugung von Transport Features auskommt und im wesentlichen auf Git merges / Pull-Requests zwischen  Branches basiert.

FS Version: 5.2.1503

fs-cli: 2.1.603

Viele Grüße,

Johannes

[CVogel · Accepted solution]

Hallo Johannes,

ok, ihr habt da zwei unterschiedliche Anwendungsfälle:

1. Vergleich der aktuellen Unterschiede zwischen DEV / QA / PROD

2. Verteilte Entwicklung + Übertragung DEV -> QA -> PROD

Den ersten Fall benötigt ihr in der Form aber nicht mehr, wenn der zweite Fall vollständig implementiert ist, korrekt?

Für den ersten Fall finde ich euren Ansatz gar nicht so schlimm (alle nicht-fachlichen Dateien ignorieren). Allerdings lässt sich der zweite Fall nicht darauf aufsetzen.

Für den zweiten Fall solltet ihr "auf der grünen Wiese" anfangen und beispielsweise euer aktuelles, zentrales Entwicklungsprojekt als Kopiervorlage für die Entwickler nehmen. Den Stand des Entwicklungsprojekts würde ich dann als initialen Stand auch ins git einchecken (develop).

Davon dann entsprechend Feature-Branches erstellen und diese auf den lokalen Entwicklungsprojekten importieren. Die kann man dann gut per Pull-Request zurück auf den develop-Branch mergen und so das zentrale Entwicklungsprojekt aktualisieren.

Dafür aber alles ausser des .FirstSpirit-Ordners aus eurer gitignore entfernen, sonst funktioniert das nicht. Es wird hierbei auch keine ID-Probleme geben.

Bitte lest euch auch die Doku durch, darin ist dieser Fall sehr gut beschrieben.

Bei Fragen zur Doku oder Verbesserungsvorschlägen gerne hier melden.

Ihr solltet auch nach Möglichkeit eure FirstSpirit-Server auf den aktuellen Release aktualisieren. Im Bereich External-Sync gibt es eigentlich fortlaufend Optimierungen (neue Features, Bugfixes).

Viele Grüße

Christian

[mikula]

Ich hab das ganze Topic mal aus dem Off nach Developers geschoben ich denke dort ist es besser aufgehoben.

[MichaelaReydt]

Hallo Johannes,

benötigst du noch weitere Hilfe oder konnten dir Christians Antworten bereits weiterhelfen? In diesem Fall wäre es super, wenn du die "richtige Antwort" entsprechend markierst.

Viele Grüße

Michaela