Release-Management

git-Struktur

Um die Struktur im git übersichtlich zu halten, werden nur zwei Haupt-Branches verwendet: master und develop. Weiterentwicklungen werden auf Basis des develop umgesetzt, Bugfixes direkt auf master. In beiden Fällen werden Tickets in Redmine angelegt, und der entsprechende Branch mit feature/<ticket_id> bzw. bug/<ticket_id> benannt. Das Übertragen der Anpassungen in die Branches erfolgt über Merge requests. Vollständige Versionen werden in den master übertragen und dort mit entsprechenden Tags versehen. Die beiden Branches master und develop bleiben dauerhaft erhalten, und werden nicht abschließend zusammen geführt.

Das Repository liegt auf GitHub unter: https://github.com/beluga-core/core

BelugaReleaseManagement.png

Entwicklungs- und Testsysteme

Die bisherigen generischen Domains auf Basis der dev-Domain der effective WEBWORK werden durch Subdomains unter der projekteigenen Domain beluga-core.de ersetzt. Für verschiedene Entwicklungsstände werden dabei unterschiedliche Subdomains genutzt.

STANDORT.beluga-core.de

Diese Adressen zeigen auf die Installationen auf der esxh-124.gbv.de. Diese Installationen sollen genutzt werden, um die jeweiligen Tickets zu bearbeiten oder zu testen:

dev.beluga-core.de

Diese Adresse zeigt jeweils auf den aktuellen Stand des develop-Branch und ist auf das belugax-Template eingestellt.
http://dev.beluga-core.de

prod.beluga-core.de

Diese Adresse zeigt jeweils auf den aktuellen Stand des master-Branch und ist auf das belugax-Template eingestellt.
http://prod.beluga-core.de

Merge requests

Nach Abschluss der Entwicklungen eines Tickets / Bugs wird ein Merge request für diesen Branch gestellt. Voraussetzungen dafür sind:

  • Unter den standort.- und belugax.standort.-Installationen muss das korrekte Verhalten im eigenen Theme und im Basis-Theme geprüft worden sein.
  • In der Beschreibung zum Merge-Request muss hinterlegt werden:
    • Was wurde angepasst?
    • Wie lässt sich das Verhalten auf standort.-, belugax.standort.- und dev-Installation nachvollziehen?
    • Beschreibung für die Release notes.

Nach erfolgreicher Prüfung durch das Releasemanagement wird der Merge request an- und der Code in den develop-/master-Branch übernommen. Die dev-Installation (und ggf. die prod-Installation) sowie die Dokumentation im Wiki werden aktualisiert.

Versionen

Die Versionsnummer ist aus drei Detailgraden aufgebaut, wobei die zugrundeliegende Version von VuFind vorangestellt wird. Die Entwicklung erfolgt in release candidate Versionen. Nach dem Abschluss wird die Version mit -rc.x-Zusatz getagged.

  • - Laufende Entwicklung (ggf. als Tag): 4.1.0-1.2.3-rc.1 = <VuFind>-<beluga-core>-rc.x
  • - Tag: 4.1.0-1.2.3
  • - <beluga-core> = 1.2.3 -> major.minor.patch (siehe https://semver.org/)

Themes & Konfiguration

Die Themes und die Konfigurationen der einzelnen Standorte sollen aus dem Repository unter GitHub heraus gehalten werden. Um die Entwicklung / Versionskontrolle nicht durch die Nutzung von Submodules oder Subtrees zu verkomplizieren, werden die Installationsverzeichnisse komplett getrennt. Die Themes-Verzeichnisse werden per Symlink eingevunde, die local-Verzeichnisse per Apache-Konfiguration. Auf dem Server ergibt sich dadurch folgende Struktur:

/opt
  |-/sites
      |-/bs.beluga-core.de
      |   |-/beluga-core -> beluga-core-4.1.0-1.0.0
      |   |-/beluga-core-4.1.0-1.0.0
      |   |    |-/themes
      |   |    |   |-/belugax_bs -> /opt/sites/beluga-config/beluga-config-4.1.0-1.0.0/themes/belugax_bs
      |   |
      |   |-/beluga-core-4.1.0-1.1.0
      |   |-/beluga-core-...
      |
      |-/fid.beluga-core.de
      |-/hi.beluga-core.de
      |-/lg.beluga-core.de
      |-/pubpharm.beluga-core.de
      |-/h.beluga-core.de
      |-/....beluga-core.de
      |
      |-/beluga-config
      |    |-beluga-config-4.1.0-1.0.0
      |    |    |-/themes
      |    |    |    |-/belugax
      |    |    |    |-/belugax_bs (Verlinkt mittels Symlink)
      |    |    |    |-/belugax_...
      |    |    |
      |    |    |-/local
      |    |        |-/local_bs (Verlinkt mittels Apache-Konfiguration)
      |    |        |-/local_lg
      |    |        |-/local_...
      |    |
      |    |-beluga-config-4.1.0-1.1.0
      |    |-beluga-config-...

Themes und Konfiguration liegen dabei jeweils in einem eigene Repository. Die Strategie beim Erzeugen und Benennen von Branches entspricht dem des Haupt-Repositories. Über die Ticketnummern lassen sich die Entwicklungen zwischen den Repositories so direkt abgleichen.

Cache

Das Cache-Verzeichnis wird von der Auslagerung ausgenommen, und über die Variable

  • SetEnv VUFIND_CACHE_DIR /opt/sites/dev.beluga-core.de/local/cache

im Installationsverzeichnis gehalten.

Coding Standards

Es gelten die Vorgaben von VuFind: https://vufind.org/wiki/development