Die Release-Einstellungen gelten pro Projekt. Öffnen Sie Releases, wählen Sie Release-Einstellungen, und wählen Sie das Projekt aus. Es gibt vier 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.
- Versionsverwaltung
- Welche Version ist das? Woher die Versionen stammen, was der Build erhält und wo Coroid prüft, was tatsächlich ausgeführt wird.
Nur Inhaber und Administrator können Release-Einstellungen ändern. Alle anderen können sie nur einsehen. Verbinden Sie zuerst ein Repository, da jede Release-Veröffentlichung auf einen Commit darin verweist.
Umgebungen
Wohin wird eine Release-Veröffentlichung geleitet und in welcher Reihenfolge?
Jedes Projekt beginnt mit Produktion. Fügen Sie die weiteren Zielumgebungen wie Staging oder QA mit Eine Umgebung hinzufügenhinzu. Geben Sie jeder Umgebung einen Namen. Coroid schlägt einen Schlüssel aus dem Namen vor, zum Beispiel staging. Ihr CI/CD verwendet diesen Schlüssel bei der Berichterstattung über ein Deployment, weshalb er nach der Nutzung durch Pipelines stabil bleiben sollte.
Legen Sie die Reihenfolge mit Kommt nachfest. Staging, das auf nichts folgt, und Produktion, die auf Staging folgt, ergeben den Pfad Staging › Produktion. Die Release-Seite zeigt den Ausrollungspfad in dieser Reihenfolge an, und Genehmigungsregeln können verlangen, dass der vorherige Schritt erfolgreich abgeschlossen wurde.
Genehmigungsregeln
Was muss erfüllt sein, bevor eine Release-Veröffentlichung hier deployed wird?
Wählen Sie oben die Umgebung aus. Die Regeln gelten pro Umgebung, sodass Staging weniger strenge Regeln hat als Produktion.
- Erforderliche Genehmigungen: wie viele verschiedene Personen müssen eine Genehmigung erteilen. Bei Null kann eine Release-Veröffentlichung sofort deployed werden, sobald die Prüfungen erfolgreich waren.
- Wer darf genehmigen: die Organisationrollen, denen die Genehmigungsberechtigung zusteht.
- Anforderer und Genehmiger getrennt halten: die Person, die das Deployment startet, darf es nicht selbst genehmigen, und wer die Release-Notes bearbeitet, darf diese nicht genehmigen.
- Qualitätsprüfungen bestanden: immer aktiviert. Der Qualitätsgraph des Projekts mit einem
release_validationTrigger wird gegen den exakten Commit ausgeführt. Veröffentlichen Sie diesen Graphen in den Qualitätseinstellungen des Projekts. - Vorherige Umgebung zuerst: die Release-Veröffentlichung muss bereits in der Umgebung deployed worden sein, auf die diese folgt.
- Genehmigte Release-Notes: die aktuellen Notes benötigen eine Genehmigung, und jede spätere Bearbeitung erfordert eine neue Genehmigung.
- 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 den 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 Genehmigungen sowie die Frage, ob die vorherige Umgebung und die Note-Genehmigung weiterhin gelten. Qualitätsprüfungen und erforderliche Checklisteneinträge gelten immer, und nur Inhaber und Administrator können Hotfixes genehmigen.
Wählen Sie Regeln veröffentlichen zum Speichern aus. Das Veröffentlichen erstellt eine neue Version der Regeln. Genehmigungen, die unter der alten Version erteilt wurden, werden ungültig, sodass eine im Laufen befindliche Release-Veröffentlichung erneut um Genehmigung bittet. 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 aus, wie Deployments gestartet werden:
- Meine Pipeline deployt automatisch: behalten Sie Ihren aktuellen Prozess bei. Coroid protokolliert Deployments, sobald Ihr CI/CD sie meldet, oder wenn ein Inhaber oder Administrator ein externes Deployment auf der Release-Seite einträgt.
- Coroid startet einen GitHub Actions-Workflow oder Coroid startet eine GitLab CI/CD-Pipeline: wird 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 das Deployment durchführt. Coroid prüft den Ref vor dem Start des Runs und den benannten Job vor der Annahme des Erfolgs.
Unter BereitstellungsberichteErstellen Sie ein Berichts-Token für die Umgebung und speichern Sie dieses als Geheimnis in Ihrem CI/CD. Coroid zeigt das Token nur einmal an und speichert lediglich einen Hash davon. Durch das Ersetzen des Tokens wird das alte Token umgehend deaktiviert. Auf demselben Bildschirm werden der Endpunkt, die Projekt-ID sowie der Umgebungsschlüssel angezeigt, die für Ihre Pipeline benötigt werden – zudem wird angezeigt, ob die Berichte eingehen. Bereitstellungsereignisse und CI-Einrichtung Enthält das Format der Ereignisse sowie Beispiele.
Versionsverwaltung
Welche Version hat diese Bereitstellung und wie wird sie beim Build verwendet?
Wählen Sie aus, woher die Version jeder Bereitstellung stammt: Coroid schlägt die nächste Version vor, Coroid liest sie aus einer Datei im Repository oder Ihre Pipeline gibt sie an. Jede Bereitstellung erhält zudem eine fortlaufende Build-Nummer. Auf dem Bildschirm werden die Werte aufgelistet, die Coroid an Ihre Pipeline übermittelt – Sie können mit einem Request Neue Aufgaben erstellen, um diese Werte zum Build hinzuzufügen – außerdem werden für jede Umgebung Version-URLs angezeigt, damit Coroid prüfen kann, welche Version jeweils ausgeführt wird. Die Version im Build integrieren enthält die Details sowie Anleitungen für Web-, Server-, Docker-, iOS- und Android-Builds.
Einstellungen zwischen Organisationen übertragen
Beim Export und Import von Einstellungen werden Umgebungen inklusive ihrer Reihenfolge, Pipeline-Konfiguration, Versionsverwaltung, Version-URLs sowie veröffentlichte Regeln – einschließlich Hotfix-Regeln – übernommen. Berichts-Tokens und Build-Nummern werden jedoch nicht exportiert. Nach einem Import müssen neue Tokens erstellt werden; jedes Projekt behält seine eigenen Build-Nummern bei.