CoroidIhre AI Software-Fabrik
Dokumentation

Wiederherstellung und Release-Züge

Auf einen fehlgeschlagenen Deployment-Vorgang oder eine fehlgeschlagene Integritätsprüfung reagieren, zu einem stabilen Commit zurückschalten und Releases mehrerer Projekte gemeinsam ausliefern.

Wenn ein Deployment fehlschlägt

Ein fehlgeschlagenes Deployment ändert niemals den Zustand, den Coroid als aktuell in der Umgebung laufend identifiziert. Der Deploy Schritt zeigt den fehlgeschlagenen Versuch samt Link zum entsprechenden Pipeline-Lauf an. Die Ursache beheben, bei Bedarf die Prüfungen erneut ausführen und anschließend erneut deployen. Jeder Versuch wird im Release-Verlauf festgehalten.

Sollte ein Versuch hängen bleiben, den Lauf in Ihrem CI/CD sowie das Berichts-Token vor einem erneuten Versuch überprüfen. Ein fehlendes Bericht bedeutet in der Regel, dass das Token oder das Ereignisformat angepasst werden muss – nicht, dass das Deployment fehlgeschlagen ist.

Wenn die Integrität Aufmerksamkeit erfordert

Nach einem erfolgreichen Deployment führt Coroid den Canary-Qualitätsgraph des Projekts aus (einen Qualitätsgraph mit einem deployment_canary Trigger), sofern dieser veröffentlicht wurde. Ein fehlgeschlagener Canary zeigt Erfordert Aufmerksamkeit im Health Schritt an. Das Deployment gilt weiterhin als erfolgreich, da der Commit tatsächlich die Umgebung erreicht hat. Die Belege des Canary sowie die Pipeline-Logs prüfen und anschließend entweder mit einem neuen Release weitermachen oder zu einem früheren Commit zurückkehren.

Zu einem stabilen Commit zurückschalten

  1. Version 2.4.0 in der ProduktivumgebungDeployt, aber die Canary-Prüfung ist fehlgeschlagenBenötigt Aufmerksamkeit
  2. Wählen Sie ein früheres, hier gesundes Release aus
  3. 2.3.1Letztes gesundes Release in ProductionIn Ordnung
Die Wiederherstellung deployt einen früheren gesunden Commit über denselben Pipeline. Beide Deployments bleiben in der Historie erhalten.

Im gerade eingesetzten Release den Health Eintrag für die Umgebung öffnen und Einen früheren stabilen Commit wiederherstellenauswählen. Dort werden frühere Releases aufgelistet, die dort eingesetzt wurden und die Integritätsprüfung bestanden haben.

  • Ihre Pipeline ist mit Coroid verbunden. Wählen Sie Rollback anfordern, geben Sie einen Branch oder Tag an, der auf den stabilen Commit verweist, und nennen Sie den Grund dafür. Coroid prüft den Referenzpunkt und startet einen neuen Lauf für das frühere Release. Die Umgebung schaltet erst um, wenn die Pipeline den Erfolg bestätigt.
  • Ihre Pipeline läuft eigenständig. Rollen Sie dort zurück. Falls Deployments gemeldet werden, zeichnet Coroid das Ergebnis automatisch auf. Kann keine Meldung erfolgen, wählen Sie Externen Rollback dokumentieren beim stabilen Release aus. Coroid prüft dabei, ob das zu ersetzende Release noch das aktuelle ist und ob das Ziel die Integritätsprüfung bestanden hat.

Sowohl das ursprüngliche Deployment als auch der Rollback bleiben im Verlauf sichtbar.

Mehrere Projekte gemeinsam ausliefern

Einige Änderungen betreffen mehrere Projekte – beispielsweise ein neues API und die darauf aufbauende Anwendung. In der Liste der Releases wählen Sie Ein Release-Train koordinieren, benennen Sie ihn und wählen Sie pro Projekt das entsprechende Release in der gewünschten Auslieferungsreihenfolge aus.

Ein Train ist eine gemeinsame Ansicht – kein einzelnes Deployment. Jedes Release behält seinen eigenen Commit, seine Prüfungen, seine Freigaben und seine Pipeline bei; jedes Release wird von seiner eigenen Seite aus ausgeliefert. Der Train zeigt Teilweise ausgeliefert an, solange einige Mitglieder ihre Umgebungen noch nicht erreicht haben – somit bleibt die restliche Arbeit sichtbar.