JensBuehring
5c9146cbec
Codegenerierung umgestellt: mit jedem Package wird der Code generiert, aber nicht mehr vom WSDL, sondern nur von den XSDs.
3.6 KiB
Schritte beim Release einer neuen Version
Dieses Dokument beschreibt das Vorgehen beim Erstellen einer neuen Version von OMDS 3.
Vorgehen im Git
Es wird das Vorgehensmodell Git-Flow verwendet.
Wir gehen vom Development-Branch aus und machen einen Release-Branch im Git. Dort werden die Änderungen vorgenommen, die vor der Veröffentlichung passieren müssen. Er steht dann als Release-Candidate zur Begutachtung zur Verfügung.
Der Release-Branch wird nach Abschluss der unten beschriebenen Schritte und nach Erstellung des Zips für die Veröffentlichung in den Master Branch gemerged.
Unter Umständen werden einige Änderungen am Release Candidate bzw. dann am Master auch in den Development-Branch rückübernommen. Damit man den Master-Branch dann wieder problemlos nach Development mergen kann und somit Development auch auf dem exakten Stand der Veröffentlichung ist, ist es sinnvoll im Development vor dem Merge den Folder für die neue Version anzulegen und diesen Folder mit den noch unveränderten XSDs zu befüllen.
Bearbeitung der Norm im Development-Branch
OMDS 2
Prüfen ob die richtige OMDS 2 XSD enthalten ist.
OMDS 3
Abgrenzung des Veröffentlichungsumfangs - nicht alles aus dem Development-Branch wird veröffentlicht.
Insbesondere ist hier um etwaige Fehler auszuschließen nochmals gegen die tatsächlich veröffentlichten XSDs der letzten Veröffentlichung zu prüfen.
Anpassung der Versions-Tags im in den XSDs und den Kommentar im WSDL.
Überarbeitung der Dokumentation
Dokumente haben einen Kopf bestehend aus:
- Titel
- Status: Empfehlung, vorgeschlagener oder freigegebener Standard
- Release: Versionsnummer des Releases
- Ansprechpartner
- Dokumentenhistorie
- Voraussetzungen
- Rechtliche Hinweise
- Inhaltsverzeichnis
Dokumente sollen im Kopf die Versionsnummer tragen, damit der Leser gleich erkennen kann, zu welcher Version das Dokument gehört.
Der Status des Service (0-Entwurf, 1-Empfehlung, 2-Vorgeschlagener Standard, 3-Freigegebener Standard) soll beim jeweiligen Service notiert sein und im Dokument ON_1.01.4_VerzeichnisOperationen.
In der Fußzeile findet sich ein Copyright Hinweis, der ggf. aktualisiert werden muss.
Abspaltung des Release Candidate
Der Release-Candidate wird als "release/Versionsnummer" vom Development-Branch abgespalten. Die Versionsnummer wird um "RC" ergänzt, behält aber den Zusatz "SNAPSHOT".
Im Release-Candidate werden die Inhalte entfernt, die im Development-Branch enthalten sind, aber nicht in den Release eingehen sollen.
Im Development-Branch wird das Verzeichnis für die nächste Version angelegt und die XSDs in dieses neue Verzeichnis übernommen. Es wird eine neue Versionsnummer mit Zusatz "SNAPSHOT" vergeben.
Merge in den Master-Branch
Versionsnummer im Pom
Die Versionsnummer im Pom ist zu setzen, ein etwaiges "SNAPSHOT" zu streichen.
Der Release-Candidate wird in den Master-Branch gemerged.
Bau der Veröffentlichung
Generierung der XSD Dokumentation mit XmlSpy
Mit Hilfe von XML-Spy die Dokumentation für jedes XSD in das Verzeichnis OMDSServiceDefinition/docGen generieren (wird nicht ins Git geladen).
JavaDoc Generierung
Es sind die Javadocs per Maven Target zu generieren (bei package inkludiert).
Build
In der Datei assembly.xml ist vorgegeben, welche Verzeichnisse für die Veröffentlichung zusammengepackt werden. In assembly.xml muss die Versionsnummmer des Release angepasst werden. Mit Maven "install" kann der Release gebaut werden.
Rückmerge in den Development-Branch
Die Definitionen der Veröffentlichung und die zugehörigen Klassen werden in den Development-Branch zurück gemerged.