Patch-Management verstehen

Wieso patchen?

Patchen möchte niemand. Wenn es dennoch sein muss, sollte es reproduzierbar, gut dokumentiert und nachvollziehbar geschehen.

Worauf ist zu achten?

Allgemein

Brandbox patched immer bezogen auf ein Package und besitzt selbst eine Abhängigkeit zum Paket "component/patch".
Damit die Abhängigkeiten korrekt aufgelöst werden, müssen patches in einem lokalen Patch-Plugin untergebracht werden.
Patches in der "patches.json" müssen einem Package zugewiesen werden (siehe Beispiel)
Paket-übergreifendes patchen erspart einem mehrere Patch-Dateien
Pfade in den Patches beginnen mit dem Package-Root.
Bei der Wahl des Pfades zur Patch-Datei ist entscheidend, ob es sich um Hotfix, Feature oder Backport handelt.

Hotfixes

Hotfixes werden in der Regel vom Customer Service erstellt und korrigieren Fehler in brandbox. Sofern man nicht bis zum nächsten Hotfix-Release warten kann, wird der Fehler mittels Patch-File korrigiert.

Die Hotfixes werden daher im Verzeichnis

www/plugin/patches/hotfix/<JIRA-TASK>.patch

Die Patches werden beim nächsten Build durch den Customer Service oder Entwickler wieder entfernt, sofern sie Bestandteil des letzten Hotfix-Releases ist.

Features

Hierbei handelt es sich um Customizing Patches, wie z.B. Anpassungen von CSS oder Erstellen von Kacheln im Dashboard. Diese sind projektabhängig und verbleiben auch bei Hotfix-Releases im Projekt.

Pfad: www/plugin/patches/custom/<JIRA-TASK>.patch

Alternativ kann der Patch auch in ein projekt-spezifisches Plugin eingefügt werden. Dies wird ebenfalls persistent behandelt.

{
  "patches": {
    "brandbox/framework": {
      "Bug #1234: Something is wrong": "plugin/patches/1234.patch"
    }
  }
}

Backports

Backports aus neueren brandbox-Versionen für das Projekt, welches sich meist in alten bb Versionen befindet, persistent.

Pfad: www/plugin/patches/backport/<JIRA-TASK>.patch

Wenn ein Backport auch in’s Produkt übetragen wird muss der Patch unter „hotfix“ landen, damit er beim Release ersetzt wird!

Patch-plugin

Ein beispielhaftes Plugin als Basis für ein eigenes, projektbezogenes Patch-Plugin findet sich in Gitlab

Beispiel

/composer.json

"extra": {
  "patches-file": "patches.json",
  "enable-patching": true
}

/patches.json

{
  "patches": {
    "example/something": {
      "Bug #1234: Something is wrong": "plugin/patches/1234.patch"
    }
  }
}

/plugin/patches/1234.patch

Fehlerbehandlung

Problem	Beschreibung

Problem	Beschreibung
Der Pfad zu PATCH-Datei stimmt nicht	patch.json liegt im www-root Die Patch-Dateien liegen in plugin/patches
Der Pfad zu den Dateien in den Patches stimmt nicht	Siehe Beispiel oben. Pfade immer beginnend mit `plugin/remote`
Es sollte nicht mit camelCase gearbeitet werden	Es sollte nicht mit camelCase in patches.json. Beispiel: `"shop/viewresult": {"Ticket-123": "plugin/patches/Ticket-123.patch"}` Nicht: `"shop/viewResult": {"Ticket-123": "plugin/patches/Ticket-123.patch"}`
Patch-Level des Systems beachten.	Nur wenn das System auf dem aktuellen Stand ist, kann es funktionieren. Es wurden nach und nach Fehler beseitigt.
Eine Patch-Datei für für viele Plugins	Es ist darauf zu achten, dass alle Plugins installiert sind, bevor das PATCH angewendet wird. Es muss daher das letzte Plugin in der Dependency-Kette gefunden werden. Das Plugin wird in der patches.json eingetragen und referenziert.