<
Developing Templates in the Cloud, 2024.12
Developing Templates in the Cloud, 2024.12
Dokumentation

Anleitung Vorlagenentwicklung

Bei der verteilten Entwicklung von FirstSpirit-Projekten können Git und FS-CLI eingesetzt werden. Ein Git-basierter Workflow ermöglicht mit Topic-Branches, Synchronisation und automatisierten Bamboo-Plänen eine effiziente Zusammenarbeit. Für mehr Kontrolle bei der Synchronisierung kann FS CLI zum lokalen Ausführen von Befehlen verwendet werden.

Verteilte Entwicklung von FirstSpirit-Projekten

Beispiel: Verteilte Entwicklung eines FirstSpirit-Demoprojekts mit Git und FS CLI.

Konzept

Der Git-basierte Entwicklungsprozess verknüpft ein FirstSpirit-Projekt mit einem Git-Repository, in welchem alle Design-Elemente, z. B. Vorlagen und technische Medien (Javascript-Bibliotheken, CSS-Dateien, etc.), enthalten sind.

Das Git-Repository hilft bei der Änderungsnachverfolgung in den entwickelten Features. So können später auftretende Probleme leichter erkannt und behoben werden.

Mit Topic-Branches in Git können mehrere Teammitglieder an unterschiedlichen Features oder Bugs arbeiten – gleichzeitig und isoliert vom Hauptprojekt bzw. anderen Entwicklern. Für jeden Git-Branch wird ein separates FirstSpirit-Branch-Projekt angelegt, in dem Entwicklung und Tests stattfinden. Nach Abschluss der Arbeit wird das Branch-Projekt unterbrechungsfrei mit dem Haupt-Projekt zusammengeführt.

ExternalSync sorgt für die Synchronisierung von Git-Branches und FirstSpirit-Projekten; ContentTransport ermöglicht das Befüllen neuer Branch-Projekte mit Beispielinhalten. Dies sichert eine höhere Entwicklerfreundlichkeit und den Transport von Inhalten zwischen den Umgebungen.

Insgesamt verbessert dieser Prozess die Effizienz und die Zusammenarbeit im Team und die Qualität der Codebasis.

Die folgenden Bamboo-Pläne unterstützen die Vorlagen-Entwicklung und -Synchronisierung:

  • Sync › FirstSpirit-Projekt → Git
    Export eines FirstSpirit-Projekts in einen Git-Branch. Ein neuer Commit auf dem Branch wird erstellt.
  • Sync › Git → FirstSpirit-Projekt
    Import von Inhalten aus einem Git-Branch in ein FirstSpirit-Projekt über ExternalSync.
  • Auto Create FirstSpirit Branch Project
    Automatische Erstellung eines neuen Branch-Projekts, wenn ein neuer Topic-Branch in das Git-Repository gepusht wird.
  • Auto Cleanup FirstSpirit Branch Projects
    Deaktivierung und Löschen von FirstSpirit-Projekten, die mit keinem Git-Branch verbunden sind weil der Branch gelöscht ist und das Projekt nicht mehr benötigt wird. Automatische Ausführung; manuelle Auslösung möglich. Das Projekt wird deaktiviert, wenn ihm kein Git-Branch zugeordnet ist. Das deaktivierte Projekt wird gelöscht, wenn es 30 Tage lang inaktiv war.

Informationen zum FirstSpirit-Projekt in der Vorlagenentwicklung für ContentCreator:
  • letzter Git-Commit
  • letzter Abgleich mit Git
  • Hyperlinks zu verwendeten Bamboo-Plänen

Git-Einrichtung

Schritte Zusatz-Informationen

Git-Installation

Einsatz von Versionskontrollsystemen (VCS)

Git-Konfiguration

Konfiguration externer Komponenten

Projekt-Einrichtung mit Bamboo-Plan

Erste Übertragung in ein leeres Git-Repository

Die folgenden Schritte sind optional:

  • Öffnen Sie das Hauptprojekt im SiteArchitect und erstellen Sie ContentTransport-Features für den Beispiel-Inhalt. Der Beispiel-Inhalt wird mit dem Bamboo-Plan "Auto Create FirstSpirit Branch Project" automatisch in den Topic-Branch-Projekten installiert.Dokumentation: Erstellen von Features
  • Vergewissern Sie sich, dass Sie sich auf dem Haupt-Entwicklungs-Branch in Git befinden (üblicherweise der "main"-Branch).
  • Bearbeiten Sie die Datei fs-project.yaml im Repository-Stammverzeichnis, um die Projektkonfiguration des Repository vorzunehmen.

version: 1
mainProject:
  name: "Name of your FirstSpirit project which needs to be exported"
  gitBranchName: "main"
externalSync:
  exportElements: "projectproperty:ALL templatestore"
features:
  defaultInstallationOptions:
    onFailure: FAIL
    force: false
  testContent:
    - name: Example Content
      options:
        useLatestRevision: true
        useRelease: true
        onFailure: WARN
        force: true
    - name: More example content for dev
      options:
        useLatestRevision: true
    - name: Picture Gallery for Dev
    - name: Videos for Dev
    - name: Extras for Dev

Erklärung

Elemente im Git-Repository

Das exportElements-Property verweist auf den Inhalt, der von dem FS CLI in das Git-Repository exportiert wird.

Die FS CLI-Dokumentation ist Teil des FS CLI-Downloads. Sie befindet sich im Verzeichnis "/docs/".
Alternative: Führen Sie FS CLI mit fs-cli help export aus.

Es müssen alle Design-bezogenen Elemente des Projekts, inkl. Vorlagen, (technischer) Medien, und relevanter Datenquellen zu technischen Inhalten enthalten sein. Konkrete Inhalte sind projektabhängig. Bei Bedarf müssen globale Einstellungen ebenfalls exportiert werden.

Empfohlen wird eine saubere Trennung zwischen Design-Elementen und Inhalt in der Struktur. Dadurch wird die Definition einer großen Anzahl an Export-Elementen und das Synchronisieren mit ContentTransport-Features vereinfacht.

Weiterhin müssen Projekteigenschaften (Nutzer, Gruppen, etc.) exportiert werden. Geben Sie dafür im Parameter zusätzlich projectproperty:ALL an. Dieser Befehl bewirkt, dass alle Projekteigenschaften in das Git-Repository exportiert werden. Falls beim Export von Projekteigenschaften mehr Kontrolle benötigt wird, können Sie diese mit projectproperty:USERS projectproperty:GROUPS etc. einzeln angeben. Sie finden eine Liste aller Projekteigenschaften für den Export in der FS CLI-Dokumentation. Im Regelfall wird aber empfohlen, sämtliche Projekteigenschaften zu exportieren.

Vollständiges Beispiel für das exportElements-Property:

projectproperty:ALL templatestore contentstore entities:translation entities:translationstudio_list entities:translationstudio_requests globalstore mediafolder:layout mediafolder:files mediafolder:logos
Content-Transport-Features

Mit "Example Content", "More example content for dev", "Picture Gallery for Dev", "Videos for Dev" und "Extras for Dev" werden Feature-Pakete im FirstSpirit-Hauptprojekt beschreiben, die in Topic-Branch-Projekten installiert werden sollen. Wenn keine Features in Branch-Projekten installiert werden sollen, müssen Sie das features-Property nicht definieren.

Committen und pushen Sie die Änderungen:

git add fs-project.yaml
git commit -m "exporting FS project to git"
git push -u origin main

Starten Sie den Bamboo-Plan Sync › FirstSpirit Project → Git für den "main"-Branch in Git. Nach erfolgreicher Ausführung des Plans entsteht ein neuer Git-Commit, der in den "main"-Branch gepusht wird. Diese Änderungen müssen anschließend mit git pull übernommen werden.

Prüfen Sie, ob das exportierte Projekt alles Benötigte und Erforderliche enthält. Am einfachsten geht das, indem wir einen zusätzlichen Git-Topic-Branch direkt aus den frisch übertragenen Änderungen erstellen:

git checkout -b feat-check-export-is-ok
git push -u origin feat-check-export-is-ok

Der Bamboo-Plan Auto Create FirstSpirit Branch Project startet daraufhin automatisch für den gerade gepushten Git-Branch feat-check-export-is-ok.

Das Durchlaufen des Plans kann mehrere Minuten dauern. Anschließend erscheint ein neues Projekt auf dem FirstSpirit-Server. Wenn Ihr Hauptprojekt z. B. "Mein FS-Projekt" heißt, erhält das neue Projekt für den Git-Branch feat-check-export-is-ok den Namen "Mein FS-Projekt (feat-check-export-is-ok)".

Öffnen Sie das neu erstellte Projekt im ContentCreator oder im SiteArchitect und prüfen Sie es. Z. B.: Werden die notwendigen CSS-Klassen angewandt und der erwartete Inhalt – benötigte Icons und Feature-Inhalte – angezeigt?

Bei fehlenden Inhalten:

  • Wechseln Sie zurück in den "main"-Branch in Git.
  • Passen Sie in der Datei fs-project.yaml das "exportElements"-Property an.
  • Committen und pushen Sie die Änderungen.
  • Starten Sie den Bamboo-Plan Sync › FirstSpirit-Projekt → Git für den "main"-Branch und lassen Sie ihn durchlaufen.
  • Übernehmen Sie die Änderungen mit git pull.
  • Wechseln Sie in den "feat-check-export-is-ok"-Branch.
  • Aktualisieren Sie den "feat-check-export-is-ok"-Branch mit git merge --ff-only main.
    (das Zusammenführen funktioniert im Schnelldurchlauf, weil nur der "main"-Branch verändert wurde)
  • Pushen Sie den aktualisierten feat-check-export-is-ok-Branch.
  • Starten Sie den dazugehörigen Bamboo-Plan Sync › Git → FirstSpirit Project und lassen Sie ihn durchlaufen.
  • Prüfen Sie das aktualisierte Projekt "Mein FS-Projekt (feat-check-export-is-ok)".

Wenn das Projekt mit dem nach Git exportierten Inhalt korrekt erstellt wurde, kann der "feat-check-export-is-ok"-Branch gelöscht werden:

git checkout main
git push --delete origin feat-check-export-is-ok
git branch -D feat-check-export-is-ok

Das entsprechende FirstSpirit-Projekt im Topic-Branch wird durch den Bamboo-Plan Auto Cleanup FirstSpirit Branch Projects automatisch deaktiviert und nach 30 Tagen Inaktivität durch denselben Plan automatisch gelöscht.

Anwendungsfall: Umsetzung einer Anforderung (#42)

Voraussetzungen

  • Der "main"-Branch in Git ist aktiv.
  • Das Projekt wurde bereits in den "main"-Branch exportiert.

Ausführung

  • Erstellen Sie einen neuen Topic-Branch in Git, z. B. "feat42", und pushen Sie ihn mit git checkout -b feat42 && git push -u origin feat42
    → Der Bamboo-Plan Auto Create FirstSpirit Branch Project für den gepushten Branch erstellt automatisch einen neuen FirstSpirit-Projekt-Branch mit dem Zusatz "(feat42)" im Namen.
  • Starten Sie den Bamboo-Plan Sync › FirstSpirit Project → Git für den gepushten Branch
    → Änderungen, die möglicherweise durch den externen Sync-Befehl von FS CLI z. B. an Gruppen und Workflows vorgenommen wurden, werden exportiert.
  • Pullen Sie die Änderungen mit git pull --ff-only.
  • Öffnen Sie den Projekt-Branch im ContentCreator oder im SiteArchitect und setzen Sie die Anforderung um.
    Starten Sie den Bamboo-Plan Sync › FirstSpirit Project → Git
    Die umgesetzte Anforderung wird in den Git-Branch feat42 exportiert.
  • Pullen Sie die Änderungen.

Wiederholen Sie die genannten Schritte, um mehrere Anforderungen zu bearbeiten.

  • Führen Sie, nachdem die Entwicklung abgeschlossen ist, den Pull-Request von Ihrem Topic-Branch " feat42" nach "main" aus.
  • Lassen Sie den erstellten Pull-Request und den zugehörigen Branch des FirstSpirit-Projekts durch einen Kollegen prüfen.
  • Mergen Sie den Pull-Request nach erfolgreicher Prüfung mit dem "main"-Branch.
  • Führen Sie den Bamboo-Plan Sync › Git → FirstSpirit Project für den "main"-Branch aus.
    → Das FirstSpirit-Hauptprojekt wird aktualisiert.
  • Löschen Sie den Topic-Branch "feat42" nach dem Umsetzen der Anforderung und der Integration der Änderungen in den "main"-Branch und in das Hauptprojekt:
    git branch -d feat42
    git push --delete origin feat42
    → Der FirstSpirit-Projekt-Branch wird durch den Bamboo-Plan Auto Cleanup FirstSpirit Branch Projects automatisch aufgeräumt.

Anwendungsfall: Umgang mit Konflikten (#23)

Voraussetzung

  • Der Topic-Branch "main" in Git ist aktiv.
  • Das Projekt wurde bereits in den Topic-Branch "main" exportiert.

Ausführung

  • Erstellen Sie einen neuen Topic-Branch in Git, z. B. "feat23" und pushen Sie ihn:
    git checkout -b feat23 && git push -u origin feat23.
  • Erstellen Sie den Topic-Branch "feat42" in Git:
    git checkout -b feat42 && git push -u origin feat42.
    Hier werden später Änderungen vorgenommen, die in Konflikt zum Topic-Branch "feat23" stehen.
  • Wiederholen Sie die Schritte aus dem vorherigen Teil.
  • Nehmen Sie einige Änderungen vor, z. B. an einer Vorlage.
  • Mergen Sie die Änderungen im Topic-Branch "main".
  • Löschen Sie den Topic-Branch "feat42".
  • Wechseln Sie in den Topic-Branch "feat23":
    git checkout feat23.
    Der Bamboo-Plan Auto Create FirstSpirit Branch Project erstellt automatisch einen neuen FirstSpirit-Projekt-Branch für den Topic-Branch "feat23".
  • Starten Sie den Bamboo-Plan Sync › FirstSpirit Project → Git für den Topic-Branch "feat23".
    Die Änderungen an der Vorlage wurden im Topic-Branch "feat42" vorgenommen . Deshalb sind sie im aktiven Topic-Branch "feat23" nicht enthalten.
  • Nehmen Sie im Topic-Branch "feat23" Änderungen vor, die in Konflikt mit den Änderungen im Topic-Branch "feat42" stehen.
    Ändern Sie z. B. dieselbe Zeile derselben Vorlage.
  • Exportieren Sie mithilfe des Bamboo-Plans Sync › FirstSpirit Project → Git die Änderungen in den Topic-Branch "feat23".
  • Führen Sie git pull --ff-only aus.
  • Erstellen Sie einen Pull-Request von Ihrem Topic-Branch "feat23" nach "main".
    Der Konflikt wird angezeigt.
  • Lösen Sie den Git-Konflikt beim Mergen von Topic-Branch "main" mit Topic-Branch "feat23".
    Verwenden Sie z. B. Ihr bevorzugtes Vergleich- und Merge-Tool:
    git fetch origin
    git merge origin/main
    Alle Merge-Konflikte sind nun behoben.
  • Pushen Sie den aktualisierten Topic-Branch "feat23":
    git push origin feat23.
  • Führen Sie den Bamboo-Plan Sync › Git → FirstSpirit Project für den Topic-Branch "feat23" erneut aus.
    Das Topic-Branch-Projekt wird aktualisiert.
  • Prüfen Sie die Korrektheit des aktualisierten Projekts (fehlende CSS-Klassen, Icons, ungültige Vorlagen etc.).
  • Vergleichen Sie den nun konfliktfreien Pull-Request mit dem zugehörigen Topic-Branch-Projekt.
  • Integrieren Sie den Pull-Request in den Topic-Branch "main".
  • Löschen Sie den Topic-Branch "feat23":
    git branch -d feat23
    git push --delete origin feat23
  • Starten Sie den Bamboo-Plan Sync › Git → FirstSpirit Project für den Topic-Branch "main".
    Das Hauptprojekt wird aktualisiert.
    Die FirstSpirit-Projekte für "feat42" und "feat23" werden durch den Bamboo-Plan Auto Cleanup FirstSpirit Branch Projects automatisch bereinigt.

Transport-Design zwischen den Umgebungen Dev, QA und Prod

Wenn in der Dev-Umgebung am Website-Design Änderungen vorgenommen oder neue Features implementiert werden, werden solche Änderungen zunächst in die QA-Umgebung und anschließend in die Prod-Umgebung übertragen. Dazu wird die ContentTransport-Funktionalität verwendet.

Der Prozess wird durch drei Bamboo-Pläne unterstützt:

  • Transport › Dev → QA
    Website-Design-Transport zwischen der Dev- und der QA-Umgebung.
  • Transport › QA → Prod
    Website-Design-Transport zwischen der QA- und der Prod-Umgebung.
  • Transport › Prod → Prod
    Website-Design-Transport zwischen unterschiedlichen Projekten in der Prod-Umgebung.
    Anwendungsfall: Mehrere Unter-Pojekte für unterschiedliche Länder mit einem zentral gesteuerten Website-Design.

Vorbereitungen

  • Erstellen Sie ein neues ContentTransport-Feature im SiteArchitect.
  • Benennen Sie das Feature, z. B. "Website Design"
  • Fügen Sie dem Feature alle Design-Elemente des Projekts hinzu.

Der Inhalt dieses Features entspricht in der Praxis genau den Elementen, die im Parameter "exportElements" von fs-project.yaml enthalten sind. Eine Ausnahme sind die Projekteigenschaften: Benutzer und Gruppen existieren üblicherweise bereits auf der Zielinstanz und müssen nicht gesondert übertragen werden. Das Feature muss sämtliche Pflicht-Abhängigkeiten beinhalten. Fehlende optionale Abhängigkeiten, z. B. Vorschauseiten für Vorlagen, stellen keinen Fehler dar.

Wenn im Website-Design-Paket Store-Elemente hinzugefügt oder entfernt werden, muss das ContentTransport-Paket ebenso angepasst werden. Das ContentTransport-Paket und der "exportElements"-Parameter in fs-project.yaml müssen immer synchronisiert bleiben.

  • Speichern Sie das Feature.
  • Definieren Sie direkt danach die Entwurfspakete in fs-project.yaml.

Beispieldefinition:

version: 1
mainProject:
  name: "Name of your FirstSpirit project"
  gitBranchName: main
externalSync:
  exportElements: projectproperty:ALL templatestore
features:
  defaultInstallationOptions:
    onFailure: FAIL
    force: false
  testContent:
    - name: Example Content
  designForQa:
    - source:
        features:
        - name: Website Design
  designForProd:
    - source:
        features:
          - name: Website Design
  designForSubprojects:
    - source:
        features:
          - name: Website Design
      target:
        projects:
          - "Name of your FirstSpirit EN country project"
          - "Name of your FirstSpirit DE country project"
          - etc...

  • Verwenden Sie den Namen des im SiteArchitect erstellten Features.
    Im Beispiel oben: "Website Design".

Die Keys "designForQa", "designForProd" und "designForSubprojects" werden in den genannten Bamboo-Plänen verwendet:
Mit den Namen wird bestimmt, welche Inhalte in die nächste Umgebung übertragen werden sollen.
Wenn Features nicht in eine bestimmte Umgebung übertragen werden müssen, kann der entsprechende YAML-Key weggelassen werden.

In den Bamboo-Plänen werden folgende properties verwendet:

Bamboo-Plan Key in fs-project.yaml
Transport › Dev → QAdesignForQa
Transport › QA → ProddesignForProd
Transport › Prod → ProddesignForSubprojects
Ein Überspringen von Umgebungen ist nicht möglich.

ContentTransport

  • Prüfen Sie vor dem Synchronisieren von Inhalten das zugehörige ContentTransport-Paket im SiteArchitect in der Dev-Umgebung auf Aktualität der Inhalte.
  • Passen Sie das Paket an, wenn sich Elemente oder Abhängigkeiten geändert haben.
  • Wählen Sie die Revision aus, die Sie transportieren möchten und speichern Sie das Feature.
  • Führen Sie einen der Pläne aus:
    Transport › Dev → QA
    Transport › QA → Prod
    Transport › Prod → Prod
    Der Transport wird gestartet. Dieser Vorgang kann mehrere Minuten dauern.
  • Prüfen Sie nach Abschluss des Transports im Zielprojekt, ob die Übertragung erfolgreich war.

Standard-Namen für QA- und Prod-Projekte

Wenn in der YAML-Datei nur der Name des Dev-Projekts festgelegt ist, wird dieser Name beim Feature-Transport sowohl für das QA- also auch für das Prod-Projekt verwendet.

Beispiel

version: 1
mainProject:
  name: www.my-project.com [DEV]
  gitBranchName: main
features:
  designForQa:
    - source:
        features:
          - name: from DEV to QA with defaults

    - source:
        features:
          - name: from DEV to QA with override for source project
        project: www.my-previous-project-with-useful-features-in-it.com [DEV]

    - source:
        features:
          - name: from DEV to QA with override for target projects
      target:
        projects:
          - www.my-other-project-1.com [QA]
          - www.my-other-project-2.com [QA]
          - www.my-other-project-3.com [QA]

Erklärung

  • Übertragung von from DEV to QA with defaults
    aus Dev-Instanz
    www.my-project.com [DEV]
    in QA-Instanz
    www.my-project.com [DEV]

Ein standardmäßiges Quell- oder Zielprojekt kann in der YAML-Datei für einzelne Features überschrieben werden:

  • Übertragung von from DEV to QA with override for source project
    aus Dev-Instanz
    www.my-previous-project-with-useful-features-in-it.com [DEV]
    in QA-Instanz
    www.my-project.com [DEV]
  • Übertragung von from DEV to QA with override for target projects
    aus Dev-Instanz
    www.my-project.com [DEV]
    in QA-Instanz
    www.my-other-project-1.com [QA]
    www.my-other-project-2.com [QA]
    www.my-other-project-3.com [QA]

Die Projekt-Namen auf Dev, QA und Prod unterscheiden sich häufig.
Wenn die Projekt-Namen für QA und Prod in der YAML-Datei festgelegt sind, werden sie sowohl für das Ziel- als auch für das Quell-Projekt verwendet.

Beispiel

version: 1

mainProject:
  name: www.my-project.com [DEV]
  gitBranchName: main
  qa: www.my-project.com [QA]
  prod: www.my-project.com [PROD]

features:
  designForQa:
    - source:
        features:
          - name: from DEV to QA with defaults

  designForProd:
    - source:
        features:
          - name: from QA to PROD with defaults

  designForSubprojects:
    - source:
        features:
          - name: from PROD to PROD with defaults
      target:
        projects:
          - www.my-other-project-1.com [PROD]
          - www.my-other-project-2.com [PROD]
          - www.my-other-project-3.com [PROD]

Erklärung

  • Verwendung von www.my-project.com [QA]
    als Standard-Zielprojekt in designForQa
    und
    als Standard-Quellprojekt in designForProd
  • Verwendung von www.my-project.com [PROD]
    als Standard-Zielprojekt in designForProd
    und
    als Standard-Quellprojekt in designForSubprojects
  • Übertragung von from DEV to QA with defaults
    aus Dev-Instanz
    www.my-project.com [DEV]
    in QA-Instanz
    www.my-project.com [QA]
  • Übertragung from QA to PROD with defaults
    aus QA-Instanz
    www.my-project.com [QA]
    in Prod-Instanz
    www.my-project.com [PROD]
  • Übertragung von from PROD to PROD with defaults
    aus
    Prod-Instanz
    www.my-project.com [PROD]
    in Prod-Instanz
    www.my-other-project-1.com [PROD]
    www.my-other-project-2.com [PROD]
    www.my-other-project-3.com [PROD]

Verteilte Entwicklung von FirstSpirit-Projekten: Lokale Verwendung von FS CLI

FS CLI kann für eine lokale Ausführung von Befehlen eingesetzt werden, z. B. für eine bessere Kontrolle über die Synchronisierungs-Schritte.

Einrichtung von FS CLI

Schritte Zusatz-Informationen

Installation von FS CLI

Kommandozeilenwerkzeug "FSDevTools"

Definition von Umgebungsvariablen für FS CLI

Beispielwerte: nachstehende Tabelle

Hinzufügen des ausführbaren FS CLI-Verzeichnisses (fs-cli/bin) zur PATH-Variablen:
FS CLI kann so vom Projektverzeichnis aus gestartet werden.

Prüfung der Verbindung zwischen FS CLI und FirstSpirit-Server

Befehl: fs-cli test

Umgebungsvariablen-Beispielwerte für FS CLI

Variable Beispielwert Beschreibung
fshostecs-dev-caas-eu-central-1-1.e-spirit.hostingFS-Server-Host
fsport443FS-Server-Port
fsmodeHTTPSVerbindungsart
fsuserusername@my-company.comBenutzername
fspwdPassw0rd!Passwort

Synchronisierung: Projekt mit Git

Der FS CLI-Befehl export wird in Bamboo-Plänen verwendet, um ein bestehendes FirstSpirit-Projekt in ein Dateisystem zu integrieren. Das Projekt wird mithilfe von Git versioniert und kann in Git gespeichert werden.

Weitere Informationen zum Export-Befehl finden Sie in der FirstSpirit-Dokumentation.

Beispiel:

fs-cli -e --syncDir fs-project --project "My FS Project" export --permissionMode ALL -- projectproperty:ALL templatestore

Synchronisierung: Git mit Projekt

Der FS CLI-Befehl import wird in Bamboo-Plänen verwendet, um mithilfe von Git versionierte Inhalte in ein FirstSpirit-Projekt auf dem Server zu integrieren. Falls das Projekt nicht existiert, wird es im Verlauf des Imports erstellt.

Im nachfolgenden Beispiel hat der Parameter --layerMapping einen für eine Cloud-Installation von FirstSpirit spezifischen Wert: "*:FirstSpiritDBA".

Weitere Informationen zum Import-Befehl und den zugehörigen Parametern finden Sie in der FirstSpirit-Dokumentation.

Beispiel:

fs-cli -e --syncDir fs-project --project "Mein FS-Projekt (my-feat-branch)" import --updateExistingPermissions --layerMapping "*:FirstSpiritDBA"

Installation von Features

Laden Sie die Feature-ZIP-Datei aus dem Hauptprojekt herunter:

fs-cli -e --project "My FS Project" feature download --name "My Feature" --file feature.zip --useLatestRevision --useRelease false

Installieren Sie das heruntergeladene Feature in einen Branch des FirstSpirit-Projekts:

fs-cli -e --project "My FS Project (my-feat-branch)" feature install --file feature.zip --layerMapping "*:FirstSpiritDBA"

Weitere Informationen zu den FSDevTools finden Sie in der FirstSpirit-Dokumentation.

Seiteninhalte