Oracle Cloud Infrastructure-Dokumentation

Deployment-Pipelines verwalten

Eine Deployment-Pipeline enthält die Anforderungen, die erfüllt werden müssen, um eine Gruppe von Artefakten für die Zielumgebung bereitzustellen.

Deployment-Pipelines enthalten verschiedene Phasen für das automatisierte Deployment. Jede Phase ist bestimmten Aktionen in der Pipeline zugeordnet. Sie können die Deployment-Pipeline auf Basis einer der folgenden Releasestrategien ausführen:

  • Blue/Green-Strategie: Dabei werden zwei identische Produktionsumgebungen (die blaue und die grüne Umgebung) ausgeführt, um Ausfallzeiten und Risiken zu reduzieren. Es ist jeweils immer nur eine der Umgebungen aktiv, und der Produktionstraffic wird in der aktiven Umgebung ausgeführt. Beispiel: Wenn die blaue Umgebung aktiv ist (Produktionsumgebung), ist die grüne Umgebung die Standbyumgebung (Staging-Umgebung) und umgekehrt. Die aktive Umgebung wechselt bei aufeinander folgenden Deployments zwischen der blauen und der grünen Umgebung. Beim Deployment einer neuen Version der Anwendung wird die neue Version in der Standbyumgebung (grün) getestet. Wenn der Test erfolgreich ist, wird der Traffic von der aktiven Umgebung (blau) in die Standbyumgebung verlagert. Die validierte Version der Software wird erfolgreich bereitgestellt. Jetzt wird die grüne Umgebung aktiv und die blaue zur Standbyumgebung. Die Blue/Green-Deployment-Strategie verringert Ausfallzeiten in einem kontinuierlichen Bereitstellungsmodell erheblich, da die Validierung neuer Releases in Standbyumgebungen erfolgt, ohne Auswirkungen auf die aktuelle Produktionsumgebung. Außerdem verringert diese Strategie das Ausfallrisiko während des Deployments, da Sie ein Rollback zur vorherigen erfolgreichen Version durchführen können, indem Sie den Produktionstraffic einfach verlagern.
  • Canary-Strategie: Dabei wird die neue Softwareversion anfänglich für die Canary-Umgebung freigegeben. Nachdem das Release erfolgreich validiert wurde, wird die Software in der Produktionsumgebung freigegeben. Auch diese Strategie reduziert wie die Blue/Green-Strategie Ausfallzeiten und Risiken im Zusammenhang mit dem Deployment. Wenn das erste Release nicht erfolgreich verläuft, wirkt sich das nicht auf die Produktionsumgebung aus. Nur erfolgreiche und genehmigte Releases werden an die Produktion übertragen.
  • Rolling-Strategie: Eine neue Version wird inkrementell in der Zielumgebung bereitgestellt, indem jeweils eine Gruppe von Hosts aktualisiert wird. Die Aktualisierung wird validiert, bevor die nächste Gruppe von Hosts aktualisiert wird. Dieser Prozess wird wiederholt, bis das Rollout der neuen Version abgeschlossen ist.

Artefakte können veränderbar oder unveränderbar sein. In Artifact Registry können Sie ein veränderbares Artefakt ersetzen. Dies wird erreicht, indem ein Artefakt in ein veränderbares Repository hochgeladen und ihm der Name eines gelöschten Artefakts zugewiesen wird. Wenn ein Artefakt mit demselben Namen vorhanden ist, löscht und ersetzt das neue Artefakt das alte Artefakt. Die DevOps-Deployment-Pipeline ruft Artefakte basierend auf Artefaktpfad und -version ab. Bei veränderbaren Artefakten kann es sich um das neueste Artefakt im Repository handeln.

Eine Phase ist eine Aktion in der Deployment-Pipeline. Der DevOps-Service umfasst vordefinierte Phasen, die leicht in einer Deployment-Pipeline verwendet werden können. Sie lauten wie folgt:

Sie können einer Pipeline mehrere Phasen hinzufügen. Phasen können sequenziell oder parallel hinzugefügt werden. Sie können eine beliebige Phase aus der Pipeline entfernen. In diesem Fall werden die Phase und die zugehörigen Ressourcen gelöscht.