Effektive Verfolgung von Konfigurationsänderungen von Entwickler zu Produkt

Diese Frage dient als Beispiel für einen Spring Boot-Dienst, kann jedoch eine beliebige Technologie sein.

Angenommen, Folgendes:

• Umgebungen (dev / QA / prod) gehören verschiedenen Teams. Dies bedeutet, dass Entwickler keinen Zugriff auf die Produktkonfiguration haben dürfen.
• Die Konfiguration (sagen wir application.properties) ist externalisiert, dh nicht Teil der Binärdatei
• In jeder Umgebung wird dieselbe Binärdatei / dasselbe Paket (z. B. service.jar) bereitgestellt und durch automatisierte Bereitstellung gesteuert

Während Änderungen am binären Artefakt (service.jar) automatisch an jede Umgebung weitergegeben werden, müssen Änderungen an der Konfiguration noch manuell durchgeführt werden, was zwangsläufig dazu führt, dass die Synchronisierung in jeder Umgebung erfolgt.

Angenommen, das Entwicklerteam fügt application.properties in seiner Umgebung einige Schlüssel-Wert-Paare hinzu. Was ist der beste Weg, um diese neuen Schlüssel aufzuzeichnen, damit sie bei der Bereitstellung im Ops-Team genau wissen, welche Schlüssel hinzugefügt werden müssen, sodass das Risiko, den neuen Dienst zu starten und zu sehen, dass er aufgrund eines fehlenden Schlüssels fehlschlägt, minimiert wird?

Ich weiß, dass manuelle Schritte erforderlich sind, aber ich würde gerne wissen, wie die Leute damit umgehen und den effektivsten Weg finden.

Dies ist hauptsächlich ein Kommunikationsproblem, aber Sie können Fehler durch einige einfache technische und organisatorische Maßnahmen weniger wahrscheinlich machen. Zunächst sollten Sie eine qualitativ hochwertige Dokumentation aller Einträge in Ihren Konfigurationsdateien sowie ein leicht zugängliches Beispiel oder eine "Standard" -Konfigurationsdatei bereitstellen. Die Beispieldatei kann automatisch in jeder Umgebung bereitgestellt werden, da sie nicht direkt vom Produktteam geändert werden soll.

Stellen Sie als Nächstes mit jeder neuen Version ein Änderungsprotokoll bereit, in dem wichtige Änderungen dokumentiert sind. Änderungen an der Konfiguration, die verhindern könnten, dass das System funktioniert, wenn sie fehlen, sind immer wichtig. Stellen Sie daher sicher, dass die Informationen vorhanden sind.

Angenommen, das Entwicklerteam fügt application.properties in seiner Umgebung einige Schlüssel-Wert-Paare hinzu. Was ist der beste Weg, um diese neuen Schlüssel aufzuzeichnen, damit sie bei der Bereitstellung im Ops-Team genau wissen, welche Schlüssel hinzugefügt werden müssen, sodass das Risiko, den neuen Dienst zu starten und zu sehen, dass er aufgrund eines fehlenden Schlüssels fehlschlägt, minimiert wird?

Der beste Weg, um das Risiko eines Ausfalls zu verringern, besteht darin, zu vermeiden, dass Ihre Anwendung so geändert wird, dass die neuen Schlüssel erforderlich sind. Daher sollte die Anwendung nach Möglichkeit abwärtskompatibel mit älteren Konfigurationsdateien sein. Häufig kann sich Ihre Anwendung sinnvoll verhalten, indem integrierte Standardwerte für die neuen Schlüssel für den Fall bereitgestellt werden, dass sie fehlen.

Wenn dies jedoch nicht möglich ist, sollte Ihr System es dem Produktteam so einfach wie möglich machen, herauszufinden, warum der neue Dienst nicht gestartet werden kann, wenn der Schlüssel fehlt. Es sollte eine eindeutige Fehlermeldung angezeigt werden, die genau angibt , welcher Schlüssel in welcher Datei fehlt und wo gegebenenfalls Informationen zum fehlenden Schlüssel oder ein Hinweis oder Beispiel für einen aussagekräftigen Eintrag für diesen Schlüssel zu finden sind.

Wenn die Konfiguration komplex ist und sich das Format so ändert, dass die manuelle Bearbeitung fehleranfällig wird, können Sie auch Tools zum Bearbeiten der Konfigurationen und zur Migration auf eine neuere Version bereitstellen.

Zum Beispiel verwende ich den Firefox-Webbrowser und mit jeder neuen Version (die ich automatisch erhalte) werden bestimmte Dinge zur lokalen Konfiguration hinzugefügt, die auf der Seite "about: config" überprüft werden kann. Dies ist vergleichbar mit der Konfiguration in Ihrer "Produktions" -Umgebung. Da die gesamte Konfiguration streng abwärtskompatibel bleibt, muss ich der Konfiguration niemals manuell neue Schlüssel hinzufügen, nur weil es eine neue Version des Browsers gibt. Und für den Fall, dass ich dort etwas ändern möchte (möglicherweise einen neuen Eintrag, der nicht Teil der vorherigen Version war), verwende ich entweder das Menü Extras / Optionen oder die Seite "Info: Konfiguration" und kann den Eintrag sowie einige finden Art der Dokumentation. Ich empfehle daher, Ihr System auf vergleichbare Weise zu implementieren.

An einem Ort, an dem ich einmal gearbeitet habe, hatten sie ein ähnliches Problem. Die Produktionskonfiguration wurde vom Build-Team gesteuert, nur sie hatten Zugriff darauf im Code-Repository. Die Konfigurationen dev, qa, test usw. konnten von jedem gesehen werden.

In Ihrem Beispiel würde ein Entwickler die Datei lokal aktualisieren, sie in die Quellcodeverwaltung einchecken und dann würde jemand das Build-Team auffordern, einen neuen Build "nur Konfiguration" durchzuführen, der Konfigurationsdateien auscheckt und bereitstellt, aber nicht neu kompiliert oder Stellen Sie die gesamte Anwendung erneut bereit.

Es lag an den Teammitgliedern, die Konfigurationsdateien für andere Umgebungen zum richtigen Zeitpunkt zu aktualisieren. Wenn es Zeit für ein Update für die Produktion war, musste das Build-Team die Datei über eine explizite Anfrage des Entwicklerteams aktualisieren, obwohl die Anfrage normalerweise einfach so aussah: "Kopieren Sie die Datei app.config von QA1 nach PROD". Sensible Dinge wie Kennwörter befanden sich in einer separaten Konfigurationsdatei, und auch hier konnte nur das Build-Team auf die Produktionskennwortdatei zugreifen. Der Unterschied war, dass die Entwickler dies normalerweise nicht tatenFordern Sie Änderungen an Kennwortdateien an, da diese keine Produktionskennwörter hatten. Das Build-Team wurde nur gebeten, ein Update durchzuführen, wenn ein neues Kennwort für einen neuen Service hinzugefügt wurde. Und selbst dann würden die Entwickler das Produktionskennwort wahrscheinlich nicht kennen, sondern nur den Schlüssel, der der Datei hinzugefügt werden soll (z. B. "newService2.password").

Die Technologie, mit der vieles verwaltet wurde, war Jenkins. Es gab auch ein internes Tool, mit dem Builds über Jenkins angefordert und geplant werden konnten.