Wie können wir verfolgen, welche Version unseres Codes in jeder Umgebung vorhanden ist?

Mein Team verwendet derzeit einen relativ einfachen Verzweigungs- / Bereitstellungsprozess, der folgendermaßen aussieht:

                ┌────────┐ ┌────┐ ┌──────┐
 Environments:  │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Builds:        │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Branches:      │ master │ │ qa │ │ prod │
                └────────┘ └────┘ └──────┘

Jede Umgebung hat einen eigenen Zweig (wir verwenden git ) und einen eigenen Build, der diesen Zweig verwendet. Wenn wir von einer Umgebung in eine andere umsteigen möchten, z. B. von DEV in QA, führen wir den masterZweig in qaeinem neuen QA-Build zusammen und starten ihn (der dann automatisch in der QA-Umgebung bereitgestellt wird).

Wir überlegen, auf einen neuen Prozess umzusteigen, bei dem es nicht mehr erforderlich ist, für jede Umgebung eine eigene Zweigstelle zu erstellen. Stattdessen würde ein einzelner Release-Build ein "Bereitstellungspaket" erstellen, das dann in einer beliebigen Umgebung bereitgestellt werden könnte. Wir stellen uns vor, ein typischer Workflow würde ungefähr so ​​aussehen:

                ┌────────┐     ┌────┐     ┌──────┐
 Environments:  │  DEV   │ ──► │ QA │ ──► │ PROD │
                └────────┘     └────┘     └──────┘

                      ▲ 
                       \ 

                        ┌───────────────┐
 Builds:                │ release build │
                        └───────────────┘

                                ▲
                                │

                ┌────────┐ ┌─────────┐
 Branches:      │ master │ │ release │
                └────────┘ └─────────┘

Das Heraufstufen von einer Umgebung in eine andere wird in der Quellcodeverwaltung nicht mehr behandelt. Stattdessen nehmen wir einfach die bereits erstellten Binärdateien (das "Bereitstellungspaket") und legen sie in der neuen Umgebung ab.

Mit diesem neuen System können wir jeden Build in jeder Umgebung bereitstellen, was mehrere Vorteile hat. Zum Beispiel ist es trivial, PROD-Fehlerbehebungen in DEV und QA zu testen. Unser derzeitiges System bietet keine einfache Möglichkeit, dies zu tun, ohne einen Zweig zurückzusetzen, was wir natürlich gerne vermeiden würden.

Der größte Nachteil dieses neuen Systems besteht darin, dass wir nicht mehr automatisch nachverfolgen können, welcher Code sich in welcher Umgebung befindet. Wenn wir eine Korrektur in PROD vornehmen müssen, haben wir keinen eigenen Zweig mehr, der mit der aktuellen Produktionscodebasis synchronisiert ist. Gleiches gilt für die Qualitätssicherung. Wenn wir eine schnelle Umstellung auf die Qualitätssicherung vorantreiben möchten, ohne die laufenden Arbeiten auszubaggern master, verfügen wir nicht mehr über eine Zweigstelle, die den aktuellen Status der Qualitätssicherungsumgebung widerspiegelt.

Wie können wir verfolgen, welcher Code in jeder Umgebung vorhanden ist?

Einige Optionen, über die wir nachdenken:

• Verwenden von Git-Tags , um zu verfolgen, welches Commit sich in welcher Umgebung befindet
• Einbetten des vom Build verwendeten git-Commits in jedes Bereitstellungspaket

Git-Tags sind das, was Sie wirklich zur Bezeichnung von Releases verwenden möchten. Der Grund dafür ist, dass sie für Sie von Bedeutung sind und verwendet werden können, um die Verknüpfung zwischen dem bereitgestellten Statuscode und allen Informationen, die der Build-Server möglicherweise hat (z. B. Build-Nummer), schnell zu erkennen.

Das ist zwar die Antwort, die Sie suchen, aber es löst nur die Hälfte des Problems. Die andere lautet: "Hey, hier ist der .[wje]arauf dem Server bereitgestellte Build, von welchem ​​Build stammt er?" Wir wissen, dass niemals unterschiedliche Versionen der Anwendung auf dev und qa oder prod bereitgestellt werden. Richtig?

Die Lösung für diesen Teil der Frage besteht darin, dass der Build-Server die Informationen in das Manifest einfügt. Ich komme von einem Maven und Svn-Beispiel, das ich vor mir habe:

<manifestEntries>
    <Specification-Title>${project.name}</Specification-Title>
    <Specification-Version>${project.version}</Specification-Version>
    <Build-Number>${build.number}</Build-Number>
    <Build-Id>${build.id}</Build-Id>
    <Svn-Revison>${svn.revision}</Svn-Revison>
</manifestEntries>

Das ist in der Maven-War-Plugin-Archivkonfiguration. Sie können es aber auch in anderen Plugins finden. Dann ist in Hudson ein Teil der Maven-Build-Aufforderung:

-Dbuild.number=${BUILD_NUMBER}
-Dsvn.revision=${SVN_REVISION}
-Dbuild.id=${BUILD_ID}

das setzt die definiert die dann maven abholen. Und dann müssen Sie nur noch in der MANIFEST.MF-Datei, die auf dem Server bereitgestellt wurde, nachsehen, um welche Version es sich handelt.

Es gibt ein Git-Plugin , das einen ähnlichen Satz von Umgebungsvariablen bietet, einschließlich:

• GIT_COMMIT - SHA des Stroms
• GIT_BRANCH - Name des Remote-Repositorys (Standardeinstellung: Origin), gefolgt vom Namen des aktuell verwendeten Zweigs, z. B. "origin / master" oder "origin / foo"

Durch die Kombination dieser beiden Methoden können Sie den Build (da die Build-Nummern vorwärts gehen und im Gegensatz zu sha-Prüfsummen eine Bedeutung haben) und das spezifische git-Commit, aus dem er erstellt wurde, leicht identifizieren.

Ein völlig anderer Ansatz wäre es, die Idee von versionskomplett abzulehnen. Sie haben nur "eine Version", die ein anderes konfigurierbares Verhalten aufweist. Der einzige Unterschied wäre, dass Sie eine gemeinsame Codebasis haben - selbst in der Produktion würden Sie Work in Progress bereitstellen : aber nicht aktiviert.

Der Unterschied besteht nur darin, dass in Ihrem Produkt verschiedene Funktionen aktiviert sind.

Die Deaktivierung / Aktivierung erfolgt über Feature-Toggles .

Vorteil: Der gesamte Release-Prozess ist vereinfacht: Sie liefern immer eine integrierte Version Ihrer Software. Jede Funktion ist immer in verfügbar master. Es werden keine zusätzlichen Zweige benötigt.

Das Zusammenführen von Features schmerzt nicht, weil: keine Zweige nicht zusammengeführt werden müssen. Es gibt keine Verwirrung darüber, welches Feature von welchem ​​Zweig stammt und hängt möglicherweise von Features aus anderen Zweigen ab oder kollidiert mit diesen. Jeder Teil kann nach Belieben aktiviert werden. Sogar ein Rollback ist nicht mehr nötig: Es ist nur ein Schaltergriff .

Ich weiß nicht, ob das funktioniert für Ihre Codebasis: die Voraussetzungen in Bezug auf die Qualität des Codes und Entwickler Disziplin sehr hoch sind - Sie mit „Bereinigung“ zu tun haben , nachdem ein Merkmal eine wird Kernfunktionalität und Sie müssen verwalten eine Reihe von Knebel ein größeres Durcheinander verhindern .

Vielleicht funktioniert es bei dir.

Wir verwenden Maven, um die Version in die Manifest-Datei zu setzen. Lassen Sie die Anwendung dann die Version anzeigen, wenn es sich um eine Webanwendung handelt, oder einen / version-Endpunkt für Webdienste.