Author: feddersen
Publication Date: 5/24/2016 12:56
+++ please scroll down for a german version of this announcement +++
Since FirstSpirit 5.1 developers are able to export templates and content to a filesystem structure or to import them back to FirstSpirit via the "External synchronization" feature.
Therefore a GUI within the SiteArchitect and an API to use this function programmatically are provided.
Futhermore we released the command line tool "FSDevTools" a few weeks ago, which can be used easily via an IDE or a command line. FSDevTools encapsulates the existing API and can be used for local development as well as a part of an automated development process.
Previous feedback and experience show that the external synchronization is mainly used programmatically in the context of a distributed development process.
The FSDevTools are more suitable for this use case than the GUI within the SiteArchitect.
For this reason we decided to omit the GUI with FS 5.2R4 (expected release at the end of May 2016). We ask all customers and partners to switch their development process to the mentioned FSDevTools or to use our API in the future.
Please contact our Technical Support if any problem occurs while changing your delevopment process.
Die graphische Oberfläche für die “Externe Synchronisation” entfällt ab FS 5.2R4
Seit FirstSpirit 5.1 können Entwickler über die Funktion "Externe Synchronisierung" Vorlagen und Inhalte in eine Dateisystem-Struktur exportieren bzw. aus dieser wieder nach FirstSpirit importieren. Dazu stehen bisher eine graphische Oberfläche im SiteArchitect und, um diese Funktion programmatisch nutzen zu können, eine API zur Verfügung.
Vor einigen Wochen haben wir zusätzlich das Kommandozeilen-Tool “FSDevTools” freigegeben, was dem Entwickler eine einfache Nutzung per Kommandozeile oder aus einer IDE heraus erlaubt. FSDevTools kapselt die vorhandene API und kann sowohl für die lokale Entwicklung als auch im Rahmen eines automatisierten Entwicklungsprozesses verwendet werden.
Das bisherige Feedback und die gesammelten Erfahrungen weisen darauf hin, dass die externe Synchronisation fast ausschließlich programmatisch, im Rahmen eines verteilten Entwicklungsprozesses, genutzt wird. Für diesen Anwendungsfall sind die FSDevTools besser geeignet, als die graphische Oberfläche im SiteArchitect.
Aus diesem Grund haben wir uns entschieden, die graphische Oberfläche ab der Version 5.2R4 (Release Ende Mai 2016) nicht mehr anzubieten. Wir bitten alle Kunden und Partner ihren Entwicklungsprozess auf die genannten FSDevTools oder unsere API umzustellen.
Sollte die Umstellung ein Problem für ihren Entwicklungsprozess darstellen, wenden Sie sich bitte an unseren Technical Support, um eine Lösung für ihren Anwendungsfall zu besprechen.
Comments
6 comments
Hallo Christoph,
ab wann kann man die FSDevTools denn produktiv einsetzen?
Was ist denn der empfohlene Weg für die Synchronisierung in Versionen vor 5.2 R4 (GUI oder CLI)?
Viele Grüße,
Jan
Hallo zusammen.
Das ist sehr gut!
Aktuell gibt es aber keine ausführliche Dokumentation. Daher sind einige Fragen offen. Wann wird die Dokumentation erweitert?
Hier 4 von mir:
Gruß,
Daniel
Hallo Christoph,
ich habe auch noch eine Frage dazu.
In der GUI konnte ich auch Datensätze (Entities) exportieren. Für das CLI Tool kann ich so eine Option bisher nicht finden. Wie kann ich Entities mit den "FSDevTools" exportieren?
Beste Grüße
Marvin
Hallo Jan,
die FSDevTools sind für den produktiven Einsatz freigegeben und werden von uns auch bereits in Produktion genutzt.
Vor R4 kannst du beide Mechanismen verwenden. Wir würden aber die Verwendung der CLI empfehlen, damit du nach einem Update auf R4 nichts umstellen musst.
Viele Grüße
Christoph
Hallo Daniel,
ich würde empfehlen, dass du Fragen zu den FSDevTools und deren Einsatz in unserem Developers Bereich stellst. Wir erweitern die Dokumentation gerne, wenn wir wissen, was fehlt. Die FSDevTools haben wir bewusst unter der Apache-Lizenz auf Github veröffentlicht, so dass jeder Entwickler daran mitarbeiten kann. Das können sowohl Funktionserweiterungen als auch Dokumentation sein.
Wie löst man Konflikte?
Die Idee ist die Konflikte über die Merge-Funktionalitäten des eingesetzen Versionkontrollsystems (VCS) zu lösen.
Wird beim Import alles in FirstSpirit überschrieben...
Die grundlegende Idee der FSDevTools ist der Einsatz mit einem VCS. Die Wahrheit sollte also immer im VCS zu finden sein. Welche Templates sich geändert haben kannst du über die Historie des VCS sehen. Deswegen haben wir uns entschieden, dass die FSDevTools immer überschreiben. Sowohl beim Import nach FirstSpirit als auch beim Export in das Dateisystem. Nur so kann man unserer Meinung nach einen verlässlichen Continuous Delivery Prozess aufsetzen.
Ich vermute, dass es keine automatische Synchronisation mehr gibt! Ist das richtig?
Das ist richtig, aus den oben genannten Gründen. Eine Synchronisation beim Import führt in der Tendenz zu unterschiedlichen Ständen auf den verschiedenen Systemen. Unsere Grundidee ist, dass alle Änderungen ins VCS eingecheckt werden müssen. Von dort aus werden sie auf die verschiedenen Systeme verteilt. Dabei möchte man nicht syncen, sondern immer überschreiben.
Wie kann ich meiner IDE, z.B. Eclipse oder IntelliJ die FirstSpirit Template Syntax beibringen?
Hier kann ich dir folgendes Projekt ans Herz legen: https://community.e-spirit.com/groups/firstspirit-languagesupport
Hallo Marvin,
Datensätze werden aktuell von den FSDevTools noch nicht unterstützt. Die FirstSpirit-API kann das aber bereits. Es fehlt also nur der entsprechende Code in den FSDevTools. Das Thema steht bereits auf unserer Wunschliste, wir würden uns aber auch sehr über einen Pullrequest freuen.
Viele Grüße
Christoph
Please sign in to leave a comment.