Questions & Answers

[mona_ketterer]

Hallo zusammen,

wir testen gerade den Einsatz der FSDevTools, um Templates in einem VCS (in unserem Fall git) versionieren zu können.

Auch wenn wir uns generell eine "intuitivere"/ "nativere" (oder wie auch immer man das nennen mag) Unterstützung ohne merge-Konflikte aufgrund interner IDs usw. wünschen würden (es gibt ja einen Eintrag in die Richtung -> https://community.e-spirit.com/ideas/1603), klappt das zumindest schonmal deutlich besser als vorher, als es keine Möglichkeit für VCS-Einsatz gab.

Wir beschränken uns derzeit noch rein auf den Templatestore.

Der Einsatz bringt uns allerdings noch nicht so viel wie erhofft, wenn wir es auf einen FS-Server beschränken. Idealerweise möchten wir damit auch den Entwicklungs- und Abnahme-Prozess abbilden, d.h. Entwicklung von Features auf DEV-Server auf Basis develop-branch, Einspielen von Features in PROD-Server, wenn sie in master-branch gemerged werden, entsprechend verteilt / mit unterschiedlichen Entwicklern und checkouts.

Daher die Frage:

Sind die FSDEVTools dafür ausgelegt, Features (also feature-branches z. B. in git, nicht die FS-eigenen Features) zwischen verschiedenen FirstSpirit-Servern (und damit bei gleichem ursprünglichen Projekt, aber verschiedenen Projektständen und auch internen IDs) zu arbeiten? Oder ist das aufgrund der mit-versionierten IDs usw. nicht empfehlenswert?

Wir haben um merge-Konflikte zu minimieren alles innerhalb von .FirstSpirit/-Verzeichnissen als ignore gesetzt.

Das funktioniert bei der Versionierung von Templates eines FS-Servers/Projekts und deren Export und Re-Import bisher wie gesagt gut.

Beim Export, Import, Re-Export und Re-Import zwischen zwei FS-Servern mit gleichem Projekt (aber unterschiedlichen Templateentwicklungsständen und unterschiedlichen internen IDs) haben wir allerdings für uns nicht wirklich erklärbare Exceptions (z. B. IllegalArgumentException aufgrund negative project-local-id eines Templates beim Import auf Server A, aber nicht Server B, obwohl das entsprechende Template auf beiden Servern mit einer negativen TemplateID vorhanden ist, u.ä.).

Solche Exceptions sind bei uns bisher nicht aufgetreten bei der Versionierung nur auf einer FS-Instanz.

Hat jemand Erfahrung mit einem solchen Szenario, oder gibt es praktische Empfehlungen für den Einsatz der FSDevTools um Templates zwischen zwei oder mehreren FS-Servern im DEV/STAGE/PROD-Szenario zu mergen?

Danke & viele Grüße

Mona

[tunnat]

Wir denken im Projekt auch über eine Synchronisierung verschiedener Instanzen per Git nach. Wir haben allerdings noch keine relevanten Erfahrungen mit den DEV-Tools sammeln können.

Ich werde hier weiter mitlesen und posten wenn wir etwas herausgefunden haben.

[mikula]

Hallo Mona,

vielen Dank erstmal für diese Rückmeldung. Welche FS Version benutzt du? Kannst du evtl. ein paar konkrete Fehler / Exceptions posten? Gerne nehmen wir auch issues im Github entgegen .

Viele Grüße

Martin

[mfiori2]

Hallo Mona,

genau das gleiche Szenario wollten wir mit den FSDevTools auch abbilden.

Wir haben auch einige negative Erfahrungen gemacht. Die von dir angesprochenen .FirstSpirit-Ordner machen einen Merge oft schwierig und sind zeitaufwändig, dabei beinhalten die Dateien eigentlich nur Meta-Informationen. Aber Vorsicht: Wir haben ebenfalls versucht diese Ordner zu ignorieren, was nach einigen Importen und Exporten dazu geführt hat, dass wir ein korruptes System hatten, das neu aufgesetzt werden musste. Wie von dir angesprochen, gibt es noch weitere Exceptions, die Probleme bereiten. So z.B. die Fehler aufgrund der internen IDs.

Der Import scheint auch nicht in der richtigen Reihenfolge abzulaufen. Wenn z.B. Scripte Datenquellen referenzieren (im Formular vom Script), schlägt der Import immer fehl. Dazu hat e-Spirit bereits ein internes Bug-Ticket eröffnet. Die Probleme gehen so weit, dass wir uns einen Maven-Job erstellt haben, der den FirstSpirit-Server automatisiert neu aufsetzt.

Es ist gut, dass das FSDevTools ein Open-Source-Projekt ist und wir hätten gerne dazu beigetragen, in dem wir Fehler gefixed hätten. Es hat sich allerdings herausgestellt, dass die Fehler nicht im Tool an sich lagen, sondern im FS-Server selbst.

Wir hatten die FS-Versionen von 5.2.311 bis 5.2.422 im Einsatz. Die Fehler schienen gleich zu bleiben und wir bekommen nach wie vor oft Exceptions, teilweise sogar beim Import in ein neu aufgesetztes Projekt.

Für uns ist das Tool in der jetzigen Version für den produktiven Einsatz nicht ausgereift genug. Wir experimentieren z.Z. mit alternativen Möglichkeiten FirstSpirit Projekte unter Versionskontrolle zu stellen.

Die Idee an sich finden wir nach wie vor gut und richtig.

Beste Grüße

Marvin

[mikula]

Hallo Mona,

wie Marvin bereits beschrieben hat gibt es viele Stellen, an denen es vorkommen kann, dass etwas nicht wie geplant funktioniert. Es wäre super, wenn du dich mit diesem Problem an unseren technical support wenden würdest.

Viele Grüße

Martin

[CVogel]

Hallo Mona,

die FS-DEV-Tools sind eine Implementierung der API der "Externen Synchronisierung".

Die "Externe Synchronisierung" ist momentan darauf ausgelegt, Dateien extern bearbeiten zu können.

Beispielsweise könnte man so, CSS-Dateien im Lieblings-CSS-Editor bearbeiten oder Templates in einer IDE.

Der Export und Import der Dateien geht dabei aber immer gegen das selbe FirstSpirit-Projekt auf dem selben FirstSpirit-Server.

Ein weiterer Anwendungsfall ist die Übertragung von Änderungen von DEV auf QA und PROD.

Dabei gibt es normalerweise folgende Ausgangsbasis:

Projekt A auf Server DEV

Projekt A auf Server QA

Projekt A auf Server PROD

Initial haben alle Projekte den selben Entwicklungsstand.

Führt man nun Änderungen (Templates, Layout-Medien) in Projekt A auf Server DEV durch, kann man diese Änderungen mit den FS-DEV-Tools von dort exportieren und in Projekt A auf QA und Projekt A auf PROD importieren.

Diese beiden Anwendungsfälle werden sowohl von den "Externen Synchronisierung" als auch von den FS-DEV-Tools vollständig unterstützt.

Den von dir beschriebenen Anwendungsfall würde man als "verteilte Entwicklung" beschreiben. Die größten Herausforderungen sind dabei die Merge-Konflikte bei parallelen Änderungen.

Diese Mergekonflikte möchte man natürlich gerne direkt im VCS auflösen.

Aktuell unterstützen wir diesen Anwendungsfall noch nicht, da es, wie von dir beschrieben, zu Merge-Konflikten in nicht fachlichen Dateien kommt (.FirstSpirit-Ordner).

Den .FirstSpirit-Ordner zu löschen oder zu ignorieren ist nicht empfohlen, da FirstSpirit darüber verschiedenste Referenzen auflöst und ein fehlerfreier Ex- oder Import nicht mehr gewährleistet werden kann.

Was man aktuell machen kann ist, bevor man seine lokalen Änderung exportiert und committed, zunächst den aktuellen Stand aus dem VCS zu pullen und einen Import nach FirstSpirit durchzuführen.

Dabei werden eventuell die lokalen Änderungen überschrieben. Diese kann man jetzt aber innerhalb von FirstSpirit über die Versionshistorie und den Merge-Dialog mergen.

Anschließend macht man einen Export, Commit und Push.

Das ist sicherlich nicht die schönste Lösung aber wir arbeiten daran, die Merge-Konflikte in nicht-fachlichen Dateien zu vermeiden und so den Merge innerhalb des VCS zu vereinfachen.

Ich hoffe, das bringt ein wenig Licht ins Dunkle.

Viele Grüße

Christian

[mona_ketterer]

Hallo Marvin,

ganz herzlichen Dank für die geschilderten Beobachtungen (und sorry für die späte Antwort - Urlaubszeit usw...) . Das deckt sich recht gut mit unseren bisherigen Erfahrungen und beruhigt mich ehrlich gesagt auch etwas, da es dann ja nicht nur an Fehlern unsererseits liegen kann. Tausend Dank auch für den Hinweis mit dem .FirstSpirit Ordner und korrupten Projekten, dann lassen wir das lieber (passt ja auch zu den weiter unten geschilderten Anleitungen).

Wir prüfen parallel ebenfalls Alternativ-Varianten, ich hoffe wir finden zeitnah eine praktikable und vor Allem sichere Lösung.

Vielen Dank nochmals und viele Grüße

Mona

[mona_ketterer]

Hallo Christian,

vielen Dank für die ausführliche Darstellung, das bringt in der Tat etwas Licht ins Dunkel!

Danke auch für den Hinweis, die .FirstSpirit Dateien nicht zu ignorieren, das hätte uns dann ggf. in Schwierigkeiten gebracht und erklärt sicher auch die Exceptions bzgl. IDs die wir hatten.

Den beschriebenen Workaround mit commit-lokale-Änderung, pull-Stand-aus-git, Import nach FS und dann Merge über Versionshistorie hatten wir testweise mal versucht, hatte sich bei uns dann aber als fehleranfällig herausgestellt. Damit will ich nciht sagen, dass es damit nicht gehen würde - es waren nur immer mehrere Schritte in genau der richtigen Reihenfolge notwendig, so dass früher oder spätereiner der Beteiligten auf einem der Systeme etwas vergessen hatte oder falsch committed, und dann hatten wir danach doch wieder Exceptions, so dass wir das in der Zusammenarbeit mit mehreren Servern und mehreren Beteiligten nicht wirklich für praktikabel halten.

Wir überlegen nun, welche anderen Möglichkeiten wir (solange der o.g. Fall noch nicht offiziell unterstützt wir)d haben um das manuell oder automatisiert irgendwie zu versionieren.

Vielen Dank nochmals an alle & viele Grüße

Mona

[astember]

Hallo zusammen,

wir versuchen aktuell ein ähnliches Szenario mit einem 2 stufigen System DEV > PROD umzusetzen.

Dabei habe ich folgendes Schaubild entwickelt.

Mir ist es bereits gelungen den TemplateStore erfolgreich in unser VCS zu integrieren. Ich würde zusätzlich gern die globalen Inhalte im VCS verwalten leider funktioniert der Parameter "globalstore" offenbar nicht richtig.

Laut Dokumentation https://github.com/e-Spirit/FSDevTools/blob/master/documentation/CLI_USAGE.md

habe ich folgenden Befehl zusammengebaut:

fs-cli-prod -sd C:\SVN\FS5SyncPROD -u *** -pwd *** export globalstore --withProjectProperties

Beim Ausführen erscheint folgender Fehler:

ERROR - Wrong input format for input string globalstore

Der gleiche Befehl klappt mit "templatestore" statt "globalstore" ohne Probleme.

Ist es jemanden gelungen die Inhalte aus dem globalstore zu exportieren und kann mir den korrekten Syntax nennen?

Hat jemand Erfahrungen mit den Import von größeren Templatemengen? Ich habe die Befürchtung, dass in einem produktiven System ein inkonsistenter Zustand entstehen kann, wenn der Import nicht richtig funktioniert. Wir haben ein sehr großes Projekt mit teils komplexen Template-Konstrukten und vielen Abhängigkeiten. Sind weitere Erfahrungswerte bzw. Probleme bekannt?