External Synchronization verwenden (Best Practice)
| Inhaltsverzeichnis |
Dieses Kapitel stellt bewährte Prozesse und Arbeitsweisen (Best-Practice) für External Synchronization in einer verteilten Entwicklungsumgebung vor.
Die nachfolgend beschriebenen Schritte stellen den Arbeitsablauf für den Entwickler dar, der bei jeder Bearbeitung von Inhalten durchgeführt werden soll. Hierbei ist es wichtig, dass gerade die Import- und Export-Schritte nach der Modifikation durchgeführt werden, um die Konsistenz der Daten sicherzustellen.
Die einzelnen Schritte beschreiben, wie Projektinhalte zwischen Dateisystem und FirstSpirit-Projekt importiert, geändert und wieder exportiert werden. Das Verwalten und Zusammenführen aller Änderungen wird dabei durch ein Versionskontrollsystem unterstützen.
Konflikte, die an unterschiedlichen Stellen während der verteilten Entwicklung auftreten und nicht automatisiert über das Versionskontrollsystem behandelt werden können, werden anhand konkreter Szenarien mit Lösungsempfehlungen im Kapitel Konflikte beheben vorgestellt.
Arbeitsablauf - Schritt für Schritt
1) Update
Vom Repository ins Dateisystem (über VCS)
Grundlage der verteilten Entwicklung ist eine zentrale FirstSpirit-Instanz (bzw. ein zentraler Entwicklungsstand). Der zentrale Entwicklungsstand wird über ein Remote-Repository allen beteiligten Entwicklern zur Verfügung gestellt. Jeder Entwickler arbeitet innerhalb seiner lokalen Entwicklungsumgebung zusätzlich mit einem eigenen, lokalen Repository.
Am Anfang jeder neuen Bearbeitung von Vorlagen steht das Holen des aktuellen Stands aus dem Remote-Repository. Dazu werden alle Änderungen aus dem zentralen Repository zunächst heruntergeladen (z. B. in Git über „fetch“) und anschließend mit dem Stand des lokalen Repositorys zusammengeführt. Aus dem lokalen Repository werden die versionierten Inhalte in den Zielordner („Sync Dir“) im lokalen Dateisystem übernommen (z. B. in Git über „checkout“ bzw. „pull“). Dabei werden die externen Änderungen (der anderen Entwickler) mit den eigenen, lokalen Änderungen zusammengeführt („merge“)
Weiterführenden Informationen siehe Update.
 |
Hinweise zur Konfliktbehandlung: Während der Aktualisierung besonders beim Zusammenführen der Änderungen können Konflikte auftreten. Mögliche Konflikte und Lösungsstrategien werden unter Konfliktbehandlung beschrieben. |
2) Import
Vom Dateisystem ins FirstSpirit-Projekt (über External Synchronization)
In Schritt 2 wird nun der aktuelle Entwicklungsstand des Projekts über FSDevTools (fs-cli import) aus dem Dateisystem in die lokale FirstSpirit-Projektinstanz importiert. Dabei werden im Projekt Objekte angelegt, aktualisiert, verschoben und entfernt.
Weiterführenden Informationen siehe Import.
3) Modification
Vorlagenentwicklung in FirstSpirit (über SiteArchitect)
In Schritt 3 erfolgt die eigentliche Vorlagenentwicklung. Der Entwickler bearbeitet die gewünschten Vorlagen oder referenzierten Elemente, legt neue Vorlagen an oder löscht bestehende Elemente.
Im Projekt: Die Vorlagenentwicklung wird direkt in der lokalen FirstSpirit-Projektinstanz durchgeführt.
Im Dateisystem: Grundsätzlich können Projektinhalte auch direkt im Dateisystem bearbeitet werden.
Diese externe Bearbeitung ist aber mit Einschränkungen verbunden.
Zusätzlich sollte nach jeder externen Bearbeitung ein Import in die lokale Projektinstanz erfolgen, um sicherzustellen, dass die externen Änderungen konsistent sind.
Weiterführende Informationen siehe Modification.
|
Hinweise zur Konfliktbehandlung: Durch die gleichzeitige Bearbeitung von Elementen durch mehrere Entwickler können Konflikte beim Importieren ins Projekt auftreten, die nicht auf Ebene des VCS erkannt werden (z. B. Namensraumkonflikte in FirstSpirit). Mögliche Konflikte und Lösungsstrategien werden unter Konfliktbehandlung beschrieben. |
4) Export
Vom FirstSpirit-Projekt ins Dateisystem (über External Synchronization)
Ist nach Abschluss der Arbeit an einem Arbeitspaket ein stabiler Stand erreicht, exportiert der Entwickler seinen aktuellen Entwicklungsstand über FSDevTools (fs-cli export). Dabei wird der Entwicklungsstand aus der lokalen FirstSpirit-Projektinstanz in den Zielordner im Dateisystem exportiert. Dabei werden im Dateisystem Objekte angelegt, aktualisiert verschoben und entfernt.
Dieser Schritt ist notwendig, um geänderte Inhalte anschließend in den zentralen Entwicklungsstand zu überführen.
Weiterführende Informationen siehe Export.
5) Commit / Push
Vom Dateisystem ins Repository (über VCS)
Der Entwicklungsstand aus dem Zielordner im lokalen Dateisystem wird zunächst im lokalen Repository bestätigt (in git z. B. über „commit“).
Anschließend werden die Änderungen aus dem lokalen Repository an das zentrale Repository gesendet (in git z. B. über „push“). Auf dieser Ebene werden die Änderungen aller beteiligten Entwickler zusammengeführt („merge“). Dabei werden unter anderem Konflikte automatisch behoben und Änderungen versioniert.
Weiterführende Informationen siehe Commit / Push.
Anmerkungen
Zu den vorgestellten Szenarien
Die vorgestellten Szenarien sind explizit auf das Modell der verteilten Entwicklung ausgelegt, d.h.:
- Es sind mehrere Entwickler beteiligt.
- Jeder Entwickler benutzt eine eigene Workstation mit einem lokalen FirstSpirit-Server.
- Die FirstSpirit-Projektdaten, an denen die Entwickler arbeiten, werden auf jedem lokalen FirstSpirit-Server in einem Projekt „DevProject“ gepflegt
- Die Daten des FirstSpirit-Projekts „DevProject“ werden über ein Git-Repository versioniert und zwischen den Arbeitsstationen der beteiligten Entwickler synchronisiert
- Das Git-Repository existiert bereits und ist unter der URL ssh://firstspirit.example/externalsync erreichbar
- Das Git-Repository wird auf jeder Workstation im Verzeichnis D:\Git\DevProject geklont
Die Szenarien verwenden das Kommandozeilenwerkzeug FSDevTools (fs-cli) sowie den kommandozeilenbasierten Git-Client (git).
|
Bei Verwendung anderer Werkzeuge zur Nutzung von External Synchronization und/oder zur Versionierung der Projektdaten können Unterschiede im Arbeitsverlauf und in den einzelnen Arbeitsschritten entstehen. |
Zur Dokumentation
Da der Entwicklungsprozess mit FirstSpirit nicht in allen Unternehmen gleich ist und es unterschiedliche Ansätze gibt, mit External Synchronization zu arbeiten, hat dieses Dokument Best-Practice-Charakter. Das bedeutet, es werden Empfehlungen gegeben, wie External Synchronization am besten eingesetzt werden kann. Aufgrund von Erfahrungen mit External Synchronization, die in realen Projekten von Kunden und Partnern gesammelt werden, können sich andere oder neue Empfehlungen ergeben.