FSDevTools - fs-cli / Entwicklungsworkflow
Author: tpilz
Publication Date: 2/28/2018 7:45
Hallo Community,
ich würde gerne mehr über eure Entwicklungsworkflows in Bezug auf die Nutzung der FSDevTools erfahren. In unserem Workflow den ich
nachfolgend kurz beschreiben möchte, stoßen wir derzeit an Grenzen um bestimmte Anwendungsfälle wie z.B. Hotfix-Releases abzudecken.
Hier mal ein kurzer Überblick über unsere Ausgangslage
- Intranet-Projekt / 5-7 Entwickler / Agile Entwicklung nach SCRUM
- 1 FirstSpirit Projekt JSP/Java (FS 5.2. R16)
- 4 FirstSpirit Umgebungen (Entwicklung, Test/QA, Demo, Produktion)
- Das Publish-System welches die generierten Seiten ausliefert besteht aus SpringBoot
für die Business Logik + Embedded Tomcat - Git / JGitFlow Branchmodell / Maven / Nexus / Jenkins
- FirstSpirit Module werden per Maven installiert
- Die Entwickler haben keine lokale FirstSpirit Instanz, die Entwicklung in
FirstSpirit findet zentral am Entwicklungssystem statt
Beginnt im Rahmen eines Sprints die Arbeit an einem neuen Feature, wird hierfür ein Feature-Branch in Git erstellt. Fällt im Rahmen des
Features auch Arbeit an Templates/Regeln an, werden diese per Feature-Toggle in den Projekteinstellungen gekapselt (CMS_IF Abfragen in den Templates).
Sobald auf einen (Feature-)Branch gepusht wird läuft ein automatisierter CI-Build durch Jenkins an. Für die automatische Installation des
Publish-Systems existieren ebenfalls Jenkins-Jobs.
Am Ende eines Sprints benutzen wir ein Maven Profil welches das fs-cli export kapselt und exportieren den Templatestore um ihn dann ins Git
zu pushen.
Der Release-Build erfolgt dann über das Maven JGitFlow Plugin und das Artefakt welches die Templates beinhaltet wird mit der Release
Versionsnummer im Nexus abgelegt.
Für das Deployment der Templates in die anderen Stages gibt es einen Jenkins Job der sich die gewünschte Version der Templates aus dem
Nexus herunterlädt und dann per fs-cli import den Import in die ausgewählte Stage durchführt.
Ausgehend von diesem Workflow haben wir jetzt folgende Herausforderungen:
- Sind am Sprintende Funktionen noch nicht fertig umgesetzt, ist es zwar so das der
Java Code auf einem Feature-Branch liegt der noch nicht in den develop Branch
gemerged wurde, die zugehörigen Änderungen in FirstSpirit werden aber auf jeden
Fall durch den Template Export mit in das Release einfließen. Hierfür sind dann die Feature-Toggles gedacht, diese
lassen sich aber nicht in alle Fällen umsetzen (DB-Schema Änderungen, Workflow-Modell).
- Sobald es notwendig wird einen Hotfix für ein produktionskritisches Problem zu erstellen,
möchten wir gerne das Entwicklungssystem auf den Software Release Stand des
Produktionssystems setzen, in dem der Fehler auftritt.
Dies sollte dadurch möglich werden das alle zugehörigen Artefakte in den jeweiligen Versionen im Nexus
liegen und entsprechende automatisierte Deployment Jobs über Jenkins verfügbar sind.
Der notwendige Template Import eines älteren Template-Standes in das Entwicklungssystem ist zwar möglich, die Auswirkungen
auf Datenquellen und Schemaänderungen sind uns da aktuell unklar. D.h. hier
könnte es dann ggf. zum Datenverlust kommen falls ein neuer Entwicklungsstand durch einen älteren Stand überschrieben wird.
Wie geht ihr mit dem Transport von Templates auf andere Stages um, bzw. wie setzt ihr die FSDevTools bei euch ein?
Arbeitet ihr mit lokalen FirstSpirit Installation und ist git dann das führende System für Templates?
Wie ist eure Strategie für Hotfixes?
Würde mich über eure Erfahrungsberichte freuen!
Viele Grüße
Thomas
Tags: branch, entwicklungsprozess, fs-cli, git, hotfix, releasemanagement
-
Author: mikula - 3/16/2018 12:27
Hallo Thomas, zunächst einmal ein großes Danke für die Einsicht in eure Landschaft.
Ich kann mir vorstellen, dass einige unserer Kunden nah, an einer solchen Landschaft sind und einige sich genau so eine wünschen - aber noch gar nicht wissen, dass dies genau das ist, was sie machen möchten.
Um es kurz zu machen, ich denke ihr seid ganz nah an einer Ideallösung dran. Ich habe von Kundenprojekten gehört, bei denen für jedes Issue/Feature ein eigener FS-Server + Branch angelegt wird. In diesen Projekten kommt auch oft CaaS zum Einsatz, daher wird dort viel mit Docker und Kubernetes gemacht.Du hattest geschrieben, dass ihr ein Maven-Profil entwickelt habt?
Am Ende eines Sprints benutzen wir ein Maven Profil welches das fs-cli export kapselt und exportieren den Templatestore um ihn dann ins Git
zu pushen.
Das hört sich spannend an, habt ihr evtl. vor dies in ein Maven-Plugin zu gießen?
Nun zu deinen Fragen:
- Sind am Sprintende Funktionen noch nicht fertig umgesetzt, ist es zwar so das der Java Code auf einem Feature-Branch liegt der noch nicht in den develop Branch gemerged wurde, die zugehörigen Änderungen in FirstSpirit werden aber auf jeden Fall durch den Template Export mit in das Release einfließen. Hierfür sind dann die Feature-Toggles gedacht, diese
lassen sich aber nicht in alle Fällen umsetzen (DB-Schema Änderungen, Workflow-Modell).
Ja - da hast du Recht und mal eben aus der Hüfte geschossen, habe ich keine perfekte Lösung für dich.
- Sobald es notwendig wird einen Hotfix für ein produktionskritisches Problem zu erstellen, möchten wir gerne das Entwicklungssystem auf den Software Release Stand des
Produktionssystems setzen, in dem der Fehler auftritt. Dies sollte dadurch möglich werden das alle zugehörigen Artefakte in den jeweiligen Versionen im Nexus liegen und entsprechende automatisierte Deployment Jobs über Jenkins verfügbar sind. Der notwendige Template Import eines älteren Template-Standes in das Entwicklungssystem ist zwar möglich, die Auswirkungen auf Datenquellen und Schemaänderungen sind uns da aktuell unklar. D.h. hier könnte es dann ggf. zum Datenverlust kommen falls ein neuer Entwicklungsstand durch einen älteren Stand überschrieben wird.
Ja, richtig - könnte. Nun ist die große Frage, könnte man an dieser Stelle mit dem Datenverlust leben? Muss man ggf. auch die DB vom jeweiligen Dev/Prod system klonen / dumpen?
Das ist leider eine Frage, die nur Ihr als Entwicklungs-Team beantworten könnt / müsst, da es einfach keine allgemeingültige Aussage gibt. Ich hoffe aber, dass auch andere Nutzer hier Ihre Erfahrungen Teilen.
Viele Grüße
Martin
0 - Sind am Sprintende Funktionen noch nicht fertig umgesetzt, ist es zwar so das der Java Code auf einem Feature-Branch liegt der noch nicht in den develop Branch gemerged wurde, die zugehörigen Änderungen in FirstSpirit werden aber auf jeden Fall durch den Template Export mit in das Release einfließen. Hierfür sind dann die Feature-Toggles gedacht, diese
-
Author: tpilz - 3/19/2018 8:54
Hallo Martin,
danke für deine Antwort.
Bezgl. des Vorgehens zum Zurücksetzen des Entwicklungssystems auf einen Release Stand sind wir wegen den Unwägbarkeiten beim DB-Schema / Referenzen auf Templates erst Mal davon abgekommen. Wir werden jetzt noch mal den von E-Spirit vorgeschlagenen Weg der verteilten Entwicklung für uns prüfen.
Zum Maven Profil kann ich sagen das wir da kein Plugin entwickeln werden. Ich beschreibe hier noch mal kurz wie wir das aktuell umgesetzt haben:
0. fs-cli in der benötigten Version von Github holen und im internen Maven Repository ablegen, das gleiche gilt für fs-access.jar
1. Im Maven Multi-Module Build gibt es ein eigenes Maven Modul für die fs-templates (Ablage der Templates unter src/main/resources/firstspirit)
2a. Die Konfiguration der Pfade erfolgt in der POM:
<fsdevtools.basepath>${project.build.directory}\fs-cli</fsdevtools.basepath>
<fsdevtools.execpath>${fsdevtools.basepath}\bin</fsdevtools.execpath>
<fsdevtools.libpath>${fsdevtools.basepath}\lib</fsdevtools.libpath>
<fsdevtools.confpath>${fsdevtools.basepath}\conf</fsdevtools.confpath>
<fsdevtools.executable>fs-cli.cmd</fsdevtools.executable>
<fsdevtools.exportsyncpath>${project.basedir}\src\main\resources\firstspirit</fsdevtools.exportsyncpath>
<fsdevtools.importsyncpath>${project.build.directory}\import\firstspirit</fsdevtools.importsyncpath>
<fsdevtools.exportcommand>export</fsdevtools.exportcommand>
<fsdevtools.importcommand>import</fsdevtools.importcommand>
<fsdevtools.testcommand>test</fsdevtools.testcommand>
<fsdevtools.store>templatestore</fsdevtools.store>
<!-- fs environment config path-->
<fs.configpath>${project.basedir}\src\main\resources\config</fs.configpath>2b. Die Konfiguration der Zielumgebungen (host, port, projekt, user, etc) welches fs-cli benötigt liegt in Properties Dateien (pro Umgebung) und kann per "properties-maven-plugin" später mit einer einfachen Angabe der Umgebung geladen werden:
<!-- load environment config -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${fs.configpath}\${fs.export.env}.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>3. Bei jeder Ausführung wird im Standard Build Ablauf die konfigurierte Version des fs-cli + fs-access.jar aus dem Maven Repository geladen und lokal entpackt.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-fs-cli</id>
<phase>validate</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeGroupIds>de.espirit.firstspirit</includeGroupIds>
<includeArtifactIds>fs-cli</includeArtifactIds>
<outputDirectory>${project.build.directory}</outputDirectory>
</configuration>
</execution>
<execution>
<id>copy-fs-access</id>
<phase>validate</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>de.espirit.firstspirit</groupId>
<artifactId>fs-access</artifactId>
<version>${firstspirit.version}</version>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${fsdevtools.libpath}</outputDirectory>
<destFileName>fs-access.jar</destFileName>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>4. Es gibt drei Profile die man ausführen kann, Export, Import und Test welche die Aktionen des fs-cli widerspiegeln, diese führen das fs-cli mit Parameter aus, hier mal Beispielhaft der Export:
<profile>
<id>export-templates</id>
<properties>
<!-- skip deploy -->
<maven.install.skip>false</maven.install.skip>
<maven.deploy.skip>true</maven.deploy.skip>
</properties>
<build>
<defaultGoal>clean install</defaultGoal><plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<id>export-templates</id>
<phase>process-resources</phase>
<configuration>
<executable>${fsdevtools.execpath}/${fsdevtools.executable}</executable>
<workingDirectory>${project.build.directory}</workingDirectory>
<arguments>
<argument>-h</argument>
<argument>${fs.host}</argument>
<argument>-port</argument>
<argument>${fs.port}</argument>
<argument>-p</argument>
<argument>${fs.project}</argument>
<argument>-u</argument>
<argument>${fs.user}</argument>
<argument>-pwd</argument>
<argument>${fs.pwd}</argument>
<argument>-sd</argument>
<argument>${fsdevtools.exportsyncpath}</argument>
<argument>${fsdevtools.exportcommand}</argument>
<argument>${fsdevtools.store}</argument>
</arguments>
</configuration>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
</plugin><plugins>
</build>
</profiles>
5. Wenn der Release Build (maven deploy) ausgeführt wird, wird aus dem Template Ordner ein ZIP Artefakt (über das
maven-assembly-plugin) welches mit der entsprechenden Version in das Maven Repository hochgeladen wird.
Bei Fragen bitte melden.
Viele Grüße
Thomas
0 -
Author: sebastianc - 3/23/2018 13:21
Hallo Thomas,
vielleicht hilft dir diese Dokumentation weiter, falls dir diese noch nicht bekannt ist.
Gruß,
Sebastian
0 -
Author: tenter - 4/12/2018 12:00
Hallo zusammen,
ich denke viele Aspekte wurden jetzt bereits umfassend besprochen. Hotfixes und Zwischenreleases lassen sich denke ich nicht schön lösen, ohne dass man nicht einen zweiten FirstSpirit-Server danebenstellt und eventuell in bestimmten Abständen das FirstSpirit-Projekt zip-exportiert und als den neuen "Initialstand" verwendet. Das könntet ihr auch in eure Maven-Setups einbauen, zum Beispiel über eine dedizierte Version des Projektes, die vor dem Sync import eingespielt werden soll. Wir selbst haben solch einen komplexeren Workflow noch nicht umgesetzt (und ich weiß auch nicht, ob das nach aktuellster Dokumentation ein zu empfehlender Workflow ist) - wir würden eher versuchen das Szenario auf Hotfixes zu beschränken, die vielleicht händisch auf Prod- und Testsystem eingepflegt werden, und nicht-releasefähige Zwischenstände zu vermeiden.
Mir ist auch kein Kunde bekannt, der ein solches Szenario abbldet, aber man weiß ja nie, vielleicht schreibt hier ja noch jemand was :smileyhappy:
Grüße,
Hannes
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
4 Kommentare