Skip to content

ReleaseManagement

Jump to bottom Edit New page
msinn edited this page Jan 24, 2021 · 87 revisions

Release Management

Auf dieser Seite werden die notwendigen Schritte zur Erstellung eines neuen Releases von SmartHomeNG beschrieben. Diese Schritte setzen auf dem Git Workflow Git-flow auf.

Bei einem Release sind die folgenden Schritte durchzuführen. Es sind grundsätzlich 3 Releasetypen möglich (Komplett Release, CORE Release und Plugins Release). Abhängig davon ist einer der beiden ersten Schritte (oder beide) auszuführen, gefolgt von den 3 weiteren Schritten.

Die Vergabeweise für Versionsnummern ist unter Versionsnummern beschrieben.

Git Workflow für das Release Management

Ein Workflow zum erstellen eines Releases ist auf der Seite Git-workflow(s)-für-SmartHomeNG ausführlich beschrieben. Dieser Workflow wurde bis zum Release 1.6.1 genutzt.

Der Workflow kann sowohl mit dem Kommandozeilen Tool git, als auch mit dem graphischen Client SoureTree durchgeführt werden. Eventuell ich es auch möglich andere graphische Clients hierfür zu nutzen. Das wurde jedoch nicht getestet.

Mit Release 1.7 kam ein vereinfachter Workflow zum Einsatz, der imp folgenden beschrieben ist. Dieser Workflow verzichtet auf einen extra anzulegenden Release Branch. Dieser Workflow ist im folgenden beschrieben.

Release Dokumentation vorbereiten

  • Release Notes für die Anwender Dokumentation schreiben/komplettieren (Text: Deutsch, Listen: Englisch)
  • Bemerkungs-Block "Arbeitsstand" und Blöcke mit '...' entfernen
  • Release Notes für die Developer Dokumentation (Verweis auf Anwender Doku) erstellen und mit Datum versehen
  • Release Datum in den Release Notes (User- und Developer-Doku) setzen
  • Release Notes für das Blog (Verweis auf Anwender Doku) erstellen und mit Datum versehen (Bild + Kategorien setzen)
    • Vorletzte Release Notes: "Wichtig" entfernen

Plugins Release von SmartHomeNG erzeugen

  • Plugins repository (develop): In __init__.py Version auf die Release-Version & branch auf 'master' setzen: 
      def plugin_release():
      return '1.7'

  def plugin_branch():
      return 'master'
  • Commiten (& pushen)
  • master branch auschecken
    • PyCharm
      • master auschecken: Menü Git/Branches -> (local Branches) origin/master -> checkout
      • pullen
  • develop branch mergen
    • PyCharm
      • VCS/Git/Branches -> (local) origin/develop - > merge into current
      • pushen
      • eventuell Plugins entfernen, die noch nicht "Production- Ready" sind und nicht mit in das Release kommen sollen
        • committen & pushen
  • develop branch auschecken
    • PyCharm
      • develop auschecken: VCS/Git/Branches -> (local) origin/develop -> checkout
  • Plugins repository (develop): In __init__.py Version auf 'nach Release' Version & branch auf 'develop' setzen: 
      def plugin_release():
      return '1.7a'

  def plugin_branch():
      return 'develop'
  • committen & pushen

Damit ist das Plugin Release erfolgt und anschließend kann im develop Branch der Plugins bereits weiterentwickelt werden!

CORE Release von SmartHomeNG erzeugen

  • Core repository (develop): In bin/shngversion.py Version auf die Release-Version & branch auf 'master' setzen: 
    # Update auf 1.6B wg. ÄNnderung bei RelativsPath Auflösung & Doku Änderungen

# Update auf 1.7 wg. Release

shNG_version = '1.7'
shNG_branch = 'master'
  • master branch auschecken
  • develop branch mergen
  • eventuell: Module und Libs entfernen, die noch nicht "Production-Ready" sind und nicht mit in das Release kommen sollen
  • committen & pushen
  • develop branch auschecken
  • Core repository (develop): In bin/shngversion.py Version auf 'nach Release' Version & branch auf 'develop' setzen: 
    # Update auf 1.6B wg. ÄNnderung bei RelativsPath Auflösung & Doku Änderungen

# Update auf 1.7 wg. Release
# Update auf 1.7a wg. Kennzeichnung des Stands als "nach dem v1.6 Release"

shNG_version = '1.7a'
shNG_branch = 'develop'
  • committen & pushen

Damit ist das Core Release erfolgt und anschließend kann im develop Branch des Core bereits weiterentwickelt werden!

Neue Version der Dokumentation bauen

Bei einem reinen Plugin Release ist es auch sinnvoll die Dokumentation neu zu bauen und zu veröffentlichen. Dabei wird zwar keine der Änderungen an den Dokuemntationsseiten aus dem Core übernommen, es werden jedoch Veränderungen an den Plugin Dokumentationen (und neue Plugins) in die Dokumentation aufgenommen.

  • Das Skript build_doc.sh aus /doc aus dem master Branch in ein leeres Verzeichnis kopieren
  • Das Skript build_doc.sh mit der Option -f -m (Doku aus dem Master Branch bauen, force checkout) starten
  • Dokumentation veröffentlichen (wichtig vor der Release Kommunikation, damit die Links zu den Release Notes nicht ins Leere laufen):
    • Die Anwender Doku (das Verzeichnis html) aus work/user/build auf den Webserver kopieren und in user umbenennen
    • bei Bedarf: Die Entwickler Doku (das Verzeichnis html) aus work/developer/build auf den Webserver kopieren und in developer umbenennen

Github Release/Tag erzeugen

  • Release/Tag für den Core
  • Release/Tag für die Plugins

Release Kommunikation

  • Blog Artikel veröffentlichen/freischalten
  • Kurzen Artikel für das Forum mit Hinweisen zum Update Prozess und Verweis auf die Release Notes erstellen
    • Artikel im Forum veröffentlichen (und "pinnen")
  • Release Info auf gitter posten
  • Im github Wiki in der Sidebar einen Link auf die Release Notes aus der Anwender Doku hinzufügen
Add a custom footer

Übersicht

Dokumentation (für Anwender und Entwickler)

Ältere Artikel zu Items

Ältere Logik Beispiele

Release Notes

Die aktuellen Release Notes und die Release Notes der zurückliegenden Versionen sind in der Dokumentation im Abschnitt Release Notes zu finden.

Updates

Work in Progress und Planungen

Entwicklung

Clone this wiki locally