Releases

Die Plattform wandelt Aufgaben und Pläne in geprüfte Pull Requests um. Sobald diese gemergt sind, eine Release beantwortet die nächste Frage: Welche dieser Arbeiten laufen wo und war die Auslieferung dorthin sicher?

Ein Release verknüpft einen bestimmten Git-Commit und verfolgt ihn durch die einzelnen Umgebungen – beispielsweise Staging und anschließend Produktion. Der Commit kann bereits auf Ihrem Deployment-Branch vorhanden sein, oder Coroid fasst offene Pull Requests zunächst zu einem Release-Pull-Request zusammen; der Merge-Commit dieses Pull Requests wird zum Release-Commit. An jedem Schritt überprüft Coroid den Commit, sammelt die von Ihnen angeforderten Genehmigungen und protokolliert die von Ihrem CI/CD gemeldete Bereitstellung. Coroid markiert ein Release niemals allein auf Grundlage eigener Angaben als bereitgestellt. Die Bestätigung erfolgt entweder durch Ihre Pipeline oder durch eine Person, die die externe Bereitstellung nachweist.

Die Kernidee in einem Überblick#

• Release: ein Commit, ein Name und eine optionale Version. Eine Version wie 2.4.0 ist optional – so funktioniert kontinuierliche Auslieferung auch ohne Tags.
• Umgebung: ein Zwischenstopp auf dem Weg zu Ihren Nutzern, etwa Staging oder Produktion. Jedes Projekt definiert seine eigenen Zwischenstopps und deren Reihenfolge.
• Rollout: welche Umgebungen das Release bisher erreicht hat.
• Arbeit: die für das Release geplanten Aufgaben sowie die darin enthaltenen gemergten Änderungen – angezeigt als erledigt von Gesamtzahl.
• Vier Schritte pro Umgebung: Prüfungen, Genehmigung, Deployment und Überwachung des Systemzustands. Die Release-Seite öffnet stets den Schritt, der Ihre Aufmerksamkeit erfordert.
• Bündelung: Ein Release, das aus offenen Pull Requests erstellt wird. Coroid führt sie in einer von Ihnen festlegbaren Reihenfolge in einen Release-Branch zusammen und öffnet anschließend einen Release-Pull-Request. Bei einem Bundle-Release gibt es einen fünften Schritt, Bündelung, vor den Prüfungen.

Eine Release auf einen Blick verstehen#

Öffnen Sie Releases im Hauptmenü für jedes Projekt oder das Releases -Reiter für genau dieses Projekt. Die Liste zeigt den Fortschritt der Arbeit der Release, ihren Rollout durch die Umgebungen sowie den aktuellen Status. Nutzen Sie die Reiter, um zwischen laufenden, bereits ausgelieferten oder geschlossenen Releases zu wechseln.

Wählen Sie eine Release aus, um ihre Seite zu öffnen.

Der Rollout-Verlauf fungiert ebenfalls als Auswahlmechanismus. Wählen Sie eine Umgebung aus, um deren vier Schritte zu sehen. Die Seite öffnet sich bei der ersten Umgebung, die die Release noch nicht erreicht hat – sodass der nächste zu erledigende Schritt bereits sichtbar ist.

Die vier Schritte in jeder Umgebung#

Prüfungen. Wählen Sie Prüfungen ausführen. Coroid wendet das für die Release definierte Qualitätsmodell des Projekts auf den exakten Commit an und bestätigt, dass jede verknüpfte Änderung innerhalb dieses Commits liegt. Auch alle erforderlichen Checklisteneinträge für die jeweilige Umgebung müssen als abgeschlossen gekennzeichnet sein. Falls etwas die Release blockiert, listet der Schritt dies auf. Änderungen am Commit oder an den verknüpften Änderungen machen frühere Prüfungen ungültig – der Schritt fordert Sie auf, diese erneut auszuführen.

Genehmigung. Sobald die Prüfungen erfolgreich waren, können die von Ihren Regeln zugelassenen Personen die Release genehmigen. Der Schritt zeigt an, wie viele Genehmigungen benötigt werden und von welchen Rollen sie ausgehen müssen. Falls Ihre Regeln genehmigte Release-Notes verlangen, werden diese hier ebenfalls genehmigt.

Deployment. Wenn Prüfungen und Genehmigungen abgeschlossen sind, ist die Release für die Umgebung bereit. Ist Coroid mit GitHub Actions oder GitLab CI/CD für diese Umgebung verbunden, wählt ein Inhaber oder Administrator In Umgebung deployen… aus – daraufhin startet Coroid die Pipeline für genau diesen Commit. Andernfalls deployt Ihr Pipeline-System eigenständig und meldet das Ergebnis zurück. In beiden Fällen wird der Schritt erst grün, wenn ein Erfolg bestätigt wird.

Health-Check. Nach einem erfolgreichen Deployment führt Coroid bei Bedarf das für das Projekt definierte Canary-Qualitätsmodell aus. Ein bestandener Canary kennzeichnet die Umgebung als gesund. Ein fehlgeschlagener Canary zeigt Erfordert Aufmerksamkeit an und bietet Möglichkeiten zur Wiederherstellung. Fehlt ein Canary-Modell, bleibt der Health-Zustand unbekannt – anstatt automatisch als gesund zu gelten.

Bedeutung der Statusanzeigen#

Bereit „Bereit“ bedeutet niemals, dass die Auslieferung bereits stattgefunden hat. Nur eine bestätigte Auslieferung bringt die Auslieferung auf der Rollout-Pipeline voran.

Workflows#

Releases für ein Projekt einrichten#

Dies muss pro Projekt einmal durchgeführt werden. Öffnen Sie Releases, wählen Sie Release-Einstellungen, und wählen Sie das Projekt aus.

1. In Umgebungen, fügen Sie Ihre Stopps hinzu und ordnen Sie sie, zum Beispiel Staging vor Production.

2. In Freigaberegeln, veröffentlichen Sie Regeln für jede Umgebung: wie viele Freigaben, von welchen Rollen und welche Checklistenelemente. Eine Umgebung kann ihre Prüfungen erst bestehen, wenn die Regeln veröffentlicht wurden.

3. In Deploy-Pipeline, entscheiden Sie, ob Coroid die Auslieferungen startet oder Ihre Pipeline dies übernimmt. Erstellen Sie anschließend ein Reporting-Token, damit Ihr CI/CD Coroid mitteilen kann, was ausgeliefert wurde.

4. In Versionsverwaltung, wählen Sie aus, woher die Version jeder Auslieferung stammt, und weisen Sie jeder Umgebung eine Versions-URL zu, damit Coroid bestätigen kann, was dort läuft.

Release-Einstellungen führt Sie durch jeden Bildschirm, und Die Version in Ihren Build integrieren zeigt, wie die Version in Ihre App gelangt.

Geplanten Arbeitsumfang ausliefern#

Verwenden Sie dies, wenn Sie im Voraus wissen, welche Elemente gemeinsam ausgeliefert werden sollen.

1. Erstellen Sie die Auslieferung frühzeitig, noch bevor ein Commit festgelegt wird. Sie beginnt als Entwurf.
2. Legen Sie die Zielauslieferung für die Aufgaben fest, die darin enthalten sein sollen. Sie erscheinen unter Geplante Aufgaben, und die Arbeitsleiste füllt sich, sobald sie abgeschlossen sind.
3. Sobald die Arbeit gemergt ist, wählen Sie Details bearbeiten und wählen Sie den Commit aus, den Sie ausliefern möchten. Coroid bestätigt, welche gemergten Änderungen der Commit enthält.
4. Gehen Sie die vier Schritte für Ihre erste Umgebung durch, anschließend für die nächste.

Offene Pull Requests bündeln#

Verwenden Sie dies, wenn viele Pull Requests von Coroid oder Ihrem Team warten und gemeinsam versandt werden sollen.

1. Wählen Sie Neues Release, wählen Sie das Projekt aus und dann Offene Pull Requests. Diese Option erfordert ein GitHub- oder GitLab-Repository; bei Projekten von Coroid wird stattdessen ein Commit erstellt.
2. Coroid listet die offenen Pull Requests in die Deployment-Branch auf – am sichersten zuerst. Ein von Coroid erstelltes pull request erscheint als dessen Aufgabe oder Plan. Coroid berücksichtigt dabei die Informationen des Providers und seiner eigenen Reviews: Prüfungen, Reviews, Größe, Konflikte und Dateien, die mehrere Pull Requests betreffen. Entwürfe, fehlgeschlagene Prüfungen, angeforderte Änderungen sowie Pull Requests aus Forks werden ausgeschlossen – mit Begründung.
3. Entfernen Sie die Auswahl von Elementen, die warten sollen, und nutzen Sie die Pfeile, um die Reihenfolge zu ändern. Ein Pull Request, der auf einem anderen aufbaut (ein gestapeltes pull request oder einer, der „depends on #12“ angibt), kommt immer danach.
4. Wählen Sie Release erstellen. Coroid erstellt release/<version> vom Deployment-Branch aus die Pull Requests in der richtigen Reihenfolge zusammenführen und einen Release-Pull-Request öffnen, der alle beteiligten Pull Requests auflistet und mit ihnen verlinkt.
5. Falls es zu einem Konflikt zwischen pull request und der Release-Branch kommt, Bündelung Schritt unterbricht hier und zeigt die Dateien an. Wählen Sie Mit Coroid lösen um den Entwickler-Agenten zum Zusammenführen zu beauftragen und den Konflikt in einer Aufgabe zu lösen, oder Weglassen um ohne diese Komponente fortzufahren.
6. Überprüfen Sie den Release-Pull-Request und mergen Sie ihn mithilfe eines Merge-Commit. Anschließend markiert Ihr Provider alle gebündelten pull request als gemergt. Coroid setzt den Merge-Commit als Release-Commit fest, protokolliert die gebündelten Pull Requests als versandte Komponenten und schließt alle noch offenen Pull Requests mit einem Link zum Release-Pull-Request.
7. Gehen Sie wie gewohnt die vier Schritte für jede Umgebung durch.

Squash- oder Rebase-Merges funktionieren ebenfalls, doch Ihr Anbieter markiert die ursprünglichen Pull Requests nicht als zusammengeführt. Coroid schließt sie stattdessen mit einem Kommentar.

Inhalt des Hauptbranches ausliefern#

Verwenden Sie dies für kontinuierliche Auslieferungen, wenn Sie alles ausliefern, was gemergt wurde.

1. Wählen Sie Neue Auslieferung und wählen Sie den Commit aus, in der Regel den neuesten auf dem Auslieferungsbranch.
2. Unter Mit Vergleich zu, wählen Sie die Umgebung aus, die Sie ersetzen möchten. Coroid listet die Pull Requests und Commits zwischen dem aktuell dort laufenden Code und Ihrem Commit auf und wählt die aus, die es verifizieren kann.
3. Sie können den Namen und die Version leer lassen, wenn Sie möchten. Coroid benennt die Auslieferung nach dem Datum und dem kurzen Commit, und die Versionsquelle des Projekts füllt die Version aus. Jede Auslieferung erhält außerdem die nächste Build-Nummer.
4. Erstellen Sie die Auslieferung und folgen Sie den vier Schritten.

Falls Ihre Pipeline bei jedem Merge ohne Abfrage durch Coroid ausliefert, kann sie dennoch jede Auslieferung melden. Wenn für einen gemeldeten Commit keine Auslieferung existiert, erstellt Coroid eine beobachtete Auslieferung dafür, klar gekennzeichnet als nicht bestandene Prüfung durch Coroid.

Dringende Korrektur ausliefern#

Ein Inhaber oder Administrator kann Dies ist ein Hotfix beim Erstellen einer Auslieferung aktivieren, den vollständigen Commit der Korrektur festlegen und begründen, warum der normale Zeitplan nicht passt. Hotfixes folgen den Hotfix-Regeln jeder Umgebung, die weniger Freigaben erfordern können. Qualitätsprüfungen und erforderliche Checklistenelemente gelten weiterhin, und nur Inhaber und Administratoren genehmigen Hotfixes.

Bei Störungen wiederherstellen#

Falls der Health-Schritt „Erfordert Aufmerksamkeit“ anzeigt, Erfordert Aufmerksamkeit, öffnen Sie Health auf der betroffenen Umgebung und wählen Sie einen früheren stabilen Commit zum erneuten Deployment aus. Wiederherstellung und Release-Trains behandelt die verfügbaren Optionen, einschließlich Pipelines, die keine Rückmeldung geben können.

Über den Chat oder Ihren Editor#

Der Chat-Assistent und der MCP-Server von Coroid bieten dieselben Release-Tools: Releases auflisten und einsehen, einen Commit auswählen, eine Vorschau der Auslieferung erstellen, eine Release vorbereiten, offene Pull Requests bündeln, Prüfungen ausführen, genehmigen, eine Auslieferung anfordern und Entwürfe für Release-Notes erstellen. Das Bündeln, Genehmigen und Deployen erfordert stets eine menschliche Bestätigung. Weitere Informationen finden Sie unter Chat-Assistent und Coroid als MCP-Server.

Mehrere Projekte gemeinsam releasen#

Ein Release-Train gruppiert Releases aus mehreren Projekten, die zusammen und in bestimmter Reihenfolge ausgeliefert werden müssen – beispielsweise ein API und die darauf aufbauende Anwendung. Weitere Details dazu finden Sie unter Wiederherstellung und Release-Trains.

Was Coroid leistet und was nicht#

• Coroid fixiert, prüft und dokumentiert. Ihr Repository und CI/CD bauen und deployen.
• Wenn Coroid Pull Requests bündelt, erstellt es den Release-Branch sowie den Release-Pull-Request. Es merged den Release-Pull-Request jedoch nicht automatisch für Sie.
• Coroid startet eine Pipeline nur, wenn Sie eine verbinden und ein Inhaber oder Administrator eine Auslieferung anfordert.
• Eine Auslieferungsanfrage ist kein Beweis. Der Rollout-Prozess schreitet nur voran, wenn Ihre Pipeline den Erfolg bestätigt oder jemand eine verifizierte externe Auslieferung dokumentiert.
• Release-Notes sind Entwürfe, die Sie bearbeiten und genehmigen. Coroid veröffentlicht sie nirgendwo.
• Ein Sprint ist eine Planungsphase, kein Auslieferungsgrenze. Ein Sprint kann mehrere Releases befüllen, und eine Release kann Arbeit aus mehreren Sprints enthalten.

Verwandte Themen#

• Release-Einstellungen
• Deployment-Events und CI-Einrichtung
• Die Versionsnummer in Ihren Build integrieren
• Wiederherstellung und Release-Trains
• Sprints
• Aufgaben, Pläne, Sprints und Arbeitsabläufe
• Qualität und Nachweis für die Überprüfung