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ügenGeben Sie jedem eine Bezeichnung. CoRoid schlägt einen Schlüssel auf Basis des Namens 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 einen Deployment-Vorgang und wie erfährt CoRoid davon?
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, wenn Ihr CI/CD diese meldet oder wenn ein Inhaber oder Administrator einen externen Deployment-Vorgang auf der Release-Seite einträgt.
- CoRoid startet einen Workflow von GitHub Actions. oder CoRoid startet eine Pipeline von GitLab CI/CD.: Dies 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 den Deployment-Vorgang ausführt. CoRoid prüft zuvor den Referenzwert und anschließend den genannten Job auf Erfolg.
Unter Bereitstellungsberichte, erstellen Sie ein Reporting-Token für die Umgebung und speichern Sie es als Geheimnis in Ihrem CI/CD. CoRoid zeigt das Token nur einmal an und speichert lediglich seinen Hash-Wert. Durch das Ersetzen des Tokens wird das alte sofort deaktiviert. Auf demselben Bildschirm werden der Endpunkt, die Projekt-ID und der Umgebungsschlüssel angezeigt, die Ihre Pipeline benötigt, sowie 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 Versionsnummer jedes Releases stammt: CoRoid schlägt die nächste Version vor, liest sie aus einer Datei im Repository oder Ihre Pipeline gibt sie an. Jedes Release erhält außerdem eine fortlaufende Build-Nummer. Der Bildschirm listet die Werte auf, die CoRoid an Ihre Pipeline übermittelt, ermöglicht das Öffnen von Neue Aufgaben, um deren Hinzufügung zum Build zu beantragen, und gibt für jede Umgebung eine Versions-URL an, damit CoRoid überprüfen kann, welche Version dort läuft. 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.