Die Release-Einstellungen befinden sich zusammen mit den übrigen Projekteinstellungen. Öffnen Sie das Projekt, nwählen Sie Einstellungen, und erweitern Sie Releases. Es gibt drei Bildschirme, und jeder beantwortet eine Frage.
- Umgebungen
- Wohin geht ein Release? Stopps hinzufügen und sie in die richtige Reihenfolge bringen.
- Freigaberegeln
- Was muss vorher erfüllt sein? Freigaben, Rollen, Checkliste und Hotfix-Regeln pro Umgebung.
- Bereitstellungspipeline
- Wer deployt und wie nimmt Coroid Kenntnis davon? Ihr Pipeline oder Coroid startet es; ein Berichts-Token ermöglicht es CI/CD, das Ergebnis zu bestätigen.
Nur Inhaber und Administrator können Release-Einstellungen ändern. Alle anderen können sie nur einsehen. Verbinden Sie zuerst ein Repository, da jedes Release auf einen Commit darin verweist.
Umgebungen
Wohin wird ein Release ausgeliefert und in welcher Reihenfolge?
Jedes Projekt beginnt mit Produktion. Fügen Sie die weiteren Ziele hinzu, auf die Sie deployen, wie z.B. Staging oder QA, über Umgebung hinzufügen. Geben Sie jeder Umgebung einen Namen. Coroid
vorschlägt dazu einen Schlüssel aus dem Namen, zum Beispiel staging. Ihr CI/CD verwendet diesen Schlüssel
bei der Berichterstattung über ein Deployment, weshalb er nach Aktivierung der Pipelines stabil bleiben muss.
Die Reihenfolge legen Sie mit Kommt nach. Ein Staging, das nach nichts kommt, und Produktion, die nach Staging folgt, ergeben den Pfad Staging › Produktion. Die Release-Seite zeigt den Ausrollungspfad in dieser Reihenfolge an, und Freigaberegeln können verlangen, dass das vorherige Ziel zuerst erfolgreich ist.
Freigaberegeln
Was muss vor einem Deployment hier erfüllt sein?
Wählen Sie oben die Umgebung aus. Die Regeln gelten pro Umgebung, sodass Staging weniger strenge und Produktion strengere Vorgaben hat.
- Erforderliche Freigaben: wie viele verschiedene Personen zustimmen müssen. Bei Null kann ein Release sofort deployen, sobald seine Prüfungen bestanden sind.
- Wer darf freigeben: die Organisationrollen, die zur Freigabe berechtigt sind.
- Antragsteller und Freigebende getrennt halten: die Person, die das Deployment startet, kann es nicht selbst freigeben, und wer die Release-Notes bearbeitet, kann diese nicht freigeben.
- Qualitätsprüfungen bestanden: immer aktiviert. Der Qualitätsgraph des Projekts mit einem
release_validationTrigger läuft gegen den exakten Commit. Veröffentlichen Sie diesen Graphen in den Qualitätseinstellungen des Projekts. - Vorherige Umgebung zuerst: das Release muss bereits in die Umgebung deployt worden sein, die dieser vorausgeht.
- Freigegebene Release-Notes: die aktuellen Notes benötigen eine Freigabe, und jede spätere Bearbeitung erfordert eine neue.
- Checkliste: manuelle Schritte, die jemand auf der Release-Seite bestätigt, wie z.B. „Datenbankmigration geprüft“. Markieren Sie einen Eintrag als erforderlich oder optional. Ein erforderlicher Eintrag kann eine vorübergehende Ausnahme zulassen. Ein Inhaber oder Administrator protokolliert einen Grund und einen Ablaufzeitpunkt von bis zu 24 Stunden; die Ausnahme gilt nur für diesen Commit und diese Umgebung.
- Hotfix-Regeln: weniger strenge Regeln für dringende Fehlerbehebungen: die Anzahl der Freigaben und ob die vorherige Umgebung sowie die Note-Freigabe weiterhin gelten. Qualitätsprüfungen und erforderliche Checklisteneinträge gelten immer, und nur Inhaber und Administrator können Hotfixes freigeben.
Wählen Sie Regeln veröffentlichen zum Speichern aus. Durch das Veröffentlichen entsteht eine neue Version der Regeln. Freigaben, die unter der alten Version gewährt wurden, werden ungültig, sodass ein laufendes Release erneut um Freigabe gebeten wird. Eine Umgebung ohne veröffentlichte Regeln kann ihre Prüfungen nicht bestehen – das wird auf dem Bildschirm angezeigt.
Deploy-Pipeline
Wer startet ein Deployment und wie erfährt Coroid vom Ergebnis?
Wählen Sie oben die Umgebung aus und anschließend, wie Deployments gestartet werden:
- Meine Pipeline deployt eigenständig: behalten Sie Ihren aktuellen Prozess bei. Coroid zeichnet Deployments auf, sobald Ihr CI/CD sie meldet, oder wenn ein Inhaber oder Administrator auf der Release-Seite ein externes Deployment dokumentiert.
- Coroid startet einen GitHub Actions-Workflow oder Coroid startet eine GitLab CI/CD-Pipeline: angezeigt, wenn das Repository des Projekts bei diesem Anbieter liegt. Geben Sie den Branch oder Tag an, der auf den Release-Commit verweist, die Workflow-Datei für GitHub sowie den exakten Namen des Jobs, der deployt. Coroid prüft den Ref vor dem Start des Laufs und den benannten Job vor der Bestätigung des Erfolgs.
Unter Deployment-Berichte, erstellen Sie ein Berichts-Token für die Umgebung und speichern Sie es als Geheimnis in Ihrem CI/CD. Coroid zeigt das Token einmal an und speichert nur seinen Hash. Das Ersetzen des Tokens stoppt das alte sofort. Auf demselben Bildschirm werden der Endpunkt, die Projekt-ID und der Umgebungsschlüssel angezeigt, die Ihre Pipeline benötigt, sowie ob Berichte eingehen. Deployment-Events und CI-Einrichtung enthält das Event-Format und Beispiele.
Einstellungen zwischen Organisationen verschieben
Beim Export und Import von Einstellungen werden Umgebungen, ihre Reihenfolge, die Pipelines-Konfiguration und die veröffentlichten Regeln, einschließlich Hotfix-Regeln, übernommen. Berichts-Tokens werden nie exportiert. Erstellen Sie nach dem Import neue Tokens.