Freigeben über

Lebenszyklus der Entwicklung

  • Artikel

Die Strategie für den Entwicklungslebenszyklus umfasst wichtige Entwurfsüberlegungen und Empfehlungen für Repository, Branch, automatisierte Builds, Bereitstellung und die Rollbackstrategie während der automatischen Erstellung von Zielzonen.

Repositorystrategie

Überlegungen zum Entwurf

  • Erwägen Sie, ein Versionskontrollsystem wie Git zu verwenden, um Ihrem Team mehr Flexibilität bei der Codefreigabe und -verwaltung bereitzustellen.

    • Git ist das Standardsystem der Branche für die Versionskontrolle. Es ist ein verteiltes Versionskontrollsystem, in dem Ihre lokale Kopie des Codes eine vollständige Version des Repositorys darstellt.

  • Sie sollten wissen, welche Unterschiede es bei Repositorystrukturen mit einem oder mehreren Repositorys gibt.

    • Bei Strukturen mit einem Repository befindet sich der gesamte Quellcode in einem einzigen Repository.
    • In Strukturen mit mehreren Repositorys werden alle Projekte in separaten Repositorys organisiert.

  • Entscheiden Sie sich für eine Sichtbarkeitseinstellung, die dem Inhalt Ihres Repositorys entspricht.

    • Auf öffentliche Repositorys kann anonym zugegriffen werden.
    • Bei privaten Projekten muss Benutzer*innen Zugriff auf das Projekt gewährt werden, und sie müssen angemeldet sein, um auf die Dienste zugreifen zu können.
    • Sie können die Sichtbarkeit für Azure DevOps Projects und GitHub-Repositorys als öffentlich und privat festlegen.

  • Erwägen Sie das Festlegen von Repositoryberechtigungen, mit denen Sie steuern können, wer zu Ihrem Quellcode beitragen und andere Features verwalten darf.

  • Erwägen Sie die Verwendung der Ressourcenbereitstellung in Azure als Infrastructure-as-Code (IaC). Mithilfe von IaC können Sie die Infrastruktur in einem deklarativen Modell verwalten und so den Konfigurationsaufwand verringern, Konsistenz zwischen Bereitstellungen sicherstellen und manuelle Umgebungskonfigurationen vermeiden.

  • Azure unterstützt IaC für Zielzonen mit:

Entwurfsempfehlungen

  • Verwenden Sie Git als Versionskontrollsystem.

  • Verwenden privater Repositorys beim Erstellen von Azure-Zielzonen

  • Verwenden Sie öffentliche Repositorys, wenn Sie nicht vertrauliche Informationen wie Automatisierungsbeispiele, öffentliche Dokumentationen und Open-Source-Material für die Zusammenarbeit freigeben.

  • Verfolgen Sie einen IaC-Ansatz für die Bereitstellung, Verwaltung, Steuerung und Unterstützung von Cloudressourcen.

Branchstrategie

Überlegungen zum Entwurf

  • Erwägen Sie die Verwendung einer Branchstrategie, mit der Teams besser zusammenarbeiten und die Versionskontrolle effizient verwalten können.

  • Erwägen Sie die Verwendung spezifischer Namenskonventionen für Ihre Branches.

  • Erwägen Sie die Verwendung von Branchberechtigungen zum Steuern von Benutzerfunktionen.

  • Erwägen Sie die Verwendung von Branchrichtlinien, um Ihr Teams dabei zu unterstützen, wichtige Entwicklungsbranches zu schützen. Richtlinien können dabei helfen, Standards bei der Codequalität und dem Change Management zu erzwingen. Beispiele für Branchrichtlinien:

  • Durch die Einführung einer Pull Request-Strategie können Sie Codeänderungen steuern, die in Branches zusammengeführt werden.

    • Definieren Sie dazu eine Mergestrategie.
    • Pull Requests sollten einfach sein und einem möglichst geringe Anzahl von Dateien umfassen, damit Prüfer*innen Commits und Änderungen effizienter überprüfen können.
    • Für Pull Requests sollten klare Titel und Beschreibungen verwendet werden, damit Prüfer*innen wissen, was beim Überprüfen des Codes zu erwarten ist.
    • Sie können Pull Request-Vorlagen verwenden.
    • Sie können Ursprungsbranches löschen, nachdem alle Pull Requests abgeschlossen wurden. Damit erhalten Sie mehr Kontrolle und können die Branches einfacher verwalten.

Entwurfsempfehlungen

  • Wenden Sie ein trunkbasiertes Entwicklungsmodell an, in dem Entwickler*innen Commits nur in einem einzigen Branch durchführen. Dieses Modell vereinfacht die Continuous Integration. Alle Featureaufgaben werden im Trunk ausgeführt und mögliche Mergekonflikte werden aufgelöst, wenn der Commit erfolgt.

  • Lassen Sie Ihr Team ein einheitliche Namenskonvention für Branches definieren und anwenden, um die erledigte Arbeit besser identifizieren zu können.

  • Legen Sie Berechtigungen fest, um zu steuern, wer Code in einem Branch Ihres Git-Repositorys lesen und aktualisieren kann. Sie können Berechtigungen für einzelne Benutzer*innen und für Gruppen festlegen.

  • Legen Sie Branchrichtlinien fest:

    • Erzwingen Sie die Verwendung von Pull Requests für das Zusammenführen von Branches im Mainbranch.
    • Erzwingen Sie eine Mindestanzahl von Prüfer*innen für Pull Requests.
    • Setzen Sie bei Änderungen an einem Branch alle Genehmigungsstimmen zurück, um sie zu entfernen, behalten Sie aber ablehnende Stimmen bei und Stimmen, die zum Warten auffordern.
    • Schließen Sie Code Reviewer automatisch ein.
    • Kommentarauflösung prüfen

  • Legen Sie als Mergestrategie Squash fest. Damit haben Sie die Möglichkeit, den Git-Verlauf von Topic-Branches zu komprimieren, wenn Pull Requests abgeschlossen sind. Anstatt jeden Commit für einen Topic-Branch dem Verlauf des Standardbranches hinzuzufügen, fügt ein Squashmerge alle Dateiänderungen einem einzelnen neuen Commit im Standardbranch hinzu.

Automatisierte Builds

Überlegungen zum Entwurf

  • Erwägen Sie die Implementierung der Continuous Integration (CI). Bei der CI wird regelmäßig der gesamte Entwicklungscode in einer zentralen Codebasis zusammengeführt. Darauf basierend werden automatisch die standardmäßigen Build- und Testprozesse ausgeführt.

  • Erwägen Sie die Verwendung von CI-Triggern:

    • Azure Repos und Git. Sie können Branches, Pfade und Tags als Trigger konfigurieren, um einen CI-Build auszuführen.
    • GitHub. Sie können Branches, Pfade und Tags als Trigger konfigurieren, um einen CI-Build auszuführen.

  • Erwägen Sie, IaC-Komponententests in Ihren Buildprozess einzuschließen, um die Syntax zu überprüfen.

    • Das ARM-Vorlagen-Testtoolkit überprüft, ob Ihre Vorlage die empfohlenen Vorgehensweisen verwendet.
    • Der Bicep-Linter überprüft Bicep-Dateien auf Syntaxfehler und Verstöße gegen bewährte Methoden.

  • Erwägen Sie das Einfügen von Komponententests in Ihren Anwendungsbuildprozess. Überprüfen Sie die für Die Azure DevOps-Pipelines verfügbaren Aufgaben.

  • Verwenden Sie Azure DevOps-Dienstverbindungen oder GitHub-Geheimnisse, um Verbindungen mit Azure zu verwalten. Jede Verbindung sollte über Zugriff mit den richtigen Berechtigungen auf Azure-Ressourcen verfügen.

  • Erwägen Sie die Verwendung von Azure Key Vault-Geheimnissen, um vertrauliche Informationen wie Kennwörter, API-Schlüssel und Zertifikate zu speichern und zu verwalten.

  • Azure DevOps-Agents können selbst oder von Microsoft gehostet werden.

    • Bei von Microsoft gehosteten Agents werden Wartung und Upgrades für Sie erledigt. Jedes Mal, wenn ein Buildauftrag ausgeführt wird, wird eine neue VM erstellt.
    • Sie richten selbstgehostete Agents ein und verwalten sie, um Buildaufträge auszuführen.

Entwurfsempfehlungen

  • Verwenden Sie die CI, um das Erstellen und Testen von Code bei jedem Commit von Änderungen an die Versionskontrolle durch ein Teammitglied zu automatisieren.

  • Schließen Sie Komponententests für IaC und Anwendungscode in Ihren Buildprozess ein.

  • Wenn möglich, verwenden Sie einen von Microsoft gehosteten Pool anstelle von selbstgehosteten Pools, da sie Isolation und eine saubere VM für jede Pipelineausführung bieten.

  • Wenn Sie Azure DevOps oder GitHub über Dienstverbindungen oder GitHub-Geheimnisse mit Azure verbinden, müssen Sie immer den Bereich definieren, damit nur auf erforderlichen Ressourcen Zugriff möglich ist.

  • Verwenden Sie Key Vault-Geheimnisse, damit keine vertraulichen Informationen wie Anmeldeinformationen (Benutzerkennwörter des virtuellen Computers), Zertifikate oder Schlüssel hartcodiert werden müssen. Verwenden Sie dann Geheimnisse als Variablen in Ihren Build- und Releaseaufträgen.

Bereitstellungsstrategie

Überlegungen zum Entwurf

  • Ziehen Sie Continuous Delivery (CD) in Betracht. CD umfasst das Erstellen, Testen, Konfigurieren und Bereitstellen eines Builds in einer Umgebung.

  • Erwägen Sie die Verwendung von Umgebungen. Umgebungen ermöglichen Ihnen, eine Sammlung von Ressourcen als Ziel eines Übermittlungsauftrag zu verwenden. Beispiele für gängige Umgebungsnamen sind:

    • Entwicklung
    • Test
    • QA
    • Staging
    • Produktion

  • Erwägen Sie die Verwendung von IaC als Teil Ihrer Strategie, um Änderungen vor der Bereitstellung zu validieren und zu bestätigen.

Entwurfsempfehlungen

  • Verwenden Sie Continuous Delivery (CD), um sicherzustellen, dass Code jederzeit bereitgestellt werden kann. Dieses Verfahren führt automatische Build-, Test- und Bereitstellungsprozesse für den Code in produktionsähnlichen Umgebungen aus. Fügen Sie Continuous Delivery hinzu, um eine vollständige CI/CD-Integration zu erzielen, die Ihnen hilft, Codefehler so früh wie möglich zu erkennen und sicherzustellen, dass Sie getestete Updates schnell freigeben können.

  • Verwenden Sie Umgebungen als Teil Ihrer Bereitstellungsstrategie. Umgebungen bieten z. B. die folgenden Vorteile:

    • Bereitstellungsverlauf
    • Nachverfolgbarkeit von Commits und Arbeitselementen
    • Diagnose der Ressourcenintegrität
    • Sicherheit

  • Schließen Sie IaC-Überprüfungen vor der Bereitstellung ein, damit Sie sich eine Vorschau von Änderungen ansehen können und Details dazu erhalten, ob eine Ressource erstellt, geändert oder gelöscht wird.

Rollbackstrategie

Überlegungen zum Entwurf

  • Erwägen Sie das Erstellen eines Rollbackplans. Durch einen Rollback einer Bereitstellung wird diese auf einen als funktionierend bekannten Zustand zurückgesetzt. Dies stellt eine wichtige Möglichkeit zur Wiederherstellung nach einer fehlerhaften Bereitstellung dar.

  • Erwägen Sie das Rückgängigmachen von Änderungen in Git, wenn Sie Änderungen in einem Commit zurücksetzen, Änderungen verwerfen oder einen früheren Zustand eines Branchs wiederherstellen müssen.

Entwurfsempfehlungen

  • Nutzen Sie das Rückgängigmachen von Änderungen in Git, wenn Sie Änderungen an committeten Dateien zurücksetzen, nicht committete Änderungen verwerfen oder einen früheren Zustand eines Branchs wiederherstellen müssen.