Eine Richtlinie ist ein benannter, versionsgebundener Satz von Qualitätsvorgaben. Richtlinien werden Projekten zugeordnet; die Vorgaben werden tatsächlich umgesetzt.
Zu den Konzepten – blockierend versus beratend, wo die Vorgaben im Ablauf platziert sind – lesen Sie Qualitätsvorgaben zuerst. Diese Seite behandelt deren Verwaltung.
Verwalten Sie sie in Qualitätskontrolle. Die Liste zeigt die Organisationseinstellungen und alle Projekte an. Wählen Sie eines aus, um zu sehen, wie neue Arbeit geprüft wird, welche Kriterien bei jeder Änderung überprüft werden, welches QA-Niveau gilt und wo die Prüfungen stattfinden. Jedes Element verfügt über einen Schalter, der die Einstellung sofort aktiviert. Die Bestätigung ermöglicht das Rückgängigmachen der Änderung, und die Einstellungen einer Zeile bestimmen die Funktionsweise der jeweiligen Prüfung.
- Organisationseinstellung3 Projekte nutzen diese Einstellung.2 von 5
- StorefrontEigene Konfiguration4 von 5
- Docs-SeiteNutzt die Standardeinstellung2 von 5
- AbrechnungsAPINutzt die Standardeinstellung2 von 5
- Mobile AppNutzt die Standardeinstellung2 von 5
- Gegen schlechten CodeEin Änderungsvorschlag wird zurückgesendet, wenn dadurch Tests geschwächt, Fehler unterdrückt, Platzhalter ausgeliefert oder technische Schulden erzeugt werden.
- Unit-TestsBei jeder Änderung werden die Unit-Tests des Repositories ausgeführt und ausgewertet.
- Browser-Tests2 von 3abweichend von der StandardeinstellungDie Browser-Journeys werden gegen die jeweilige Änderung getestet.
- Übersetzungenabweichend von der StandardeinstellungEs wird überprüft, ob geänderte Texte übersetzt wurden und ob ihre Platzhalter sowie Pluralformen korrekt übereinstimmen.
- Repository-PrüfungenEigene Befehle wie Formatierungen, Dateigrößenprüfungen, Migrationen, Integrationstests und Sicherheitsscans werden ausgeführt.
- Gründliche QAGründlichBei aktivierter Funktion sammelt das QA-System live Belege und Screenshots im Vergleich zur Spezifikation. Ist sie deaktiviert, erfolgt die Standard-QA.
Qualitätskontrolle: Die gültigen Richtlinien und der letzte Gate-Lauf. Beispieldaten.
Eine Richtlinie erstellen
Eine Richtlinie besteht aus einer Reihe von Prüfungen sowie der Angabe, ob ein Fehler blockierend oder nur beratend wirkt.
Die meisten Organisationen benötigen zwei oder drei Richtlinien, nicht eine pro Projekt:
- eine strenge Richtlinie für Produktivsysteme
- eine standardmäßige Richtlinie für den regulären Betrieb
- gelegentlich eine einfache Richtlinie für interne Tools und Prototypen
Mehr als das kann niemand mehr nachvollziehen, welches Projekt welche Richtlinie nutzt.
Die Organisationseinstellungen und die individuelle Konfiguration eines Projekts
Ein Projekt folgt den Organisationseinstellungen, bis Sie einen der Schalter ändern. Diese Änderung erzeugt eine eigene Konfiguration, die von den Standardeinstellungen kopiert wird; spätere Änderungen an den Standardeinstellungen wirken sich dann nicht mehr darauf aus. Eine Zeile kann eine Prüfung aus den Standardeinstellungen übernehmen, und das Projektmenü kann das gesamte Projekt auf die Organisationseinstellungen zurücksetzen. Die vollständige Richtlinie hinter den Schaltern – einschließlich Erwartungen, Abhängigkeiten zwischen Prüfungen, Reparaturbudgets und Versionen – öffnet sich über dasselbe Menü wie der erweiterte Editor. Bei einem Projekt, das den Standard nutzt, startet der Editor mit einer Kopie davon, und es ändert sich nichts für das Projekt, bis Sie diese Kopie veröffentlichen.
Legen Sie als Standard Ihre standardmäßige Prüfungen fest, die die meisten Projekte durchführen sollten – nicht die strengsten; diese sollten gezielt, projektweise aktiviert werden.
Pull Requests
Pull Requests, die von Personen oder anderen Tools geöffnet werden, gelangen über die Coroid GitHub App zu Coroid. Die Pull Requests Gruppe in der Qualitätskontrolle entscheidet über deren weiteren Verlauf – sowohl für die Organisationseinstellungen als auch für jedes Projekt:
- Coroid Qualitätskontrolle führt die oben genannten Prüfungen bei jedem pull request durch und meldet das Ergebnis als Coroid Qualitätskontrolle-Prüfung auf GitHub.
- Coroid Rezension lässt Coroid's Reviewer jeden pull request lesen und zu den betreffenden Zeilen Kommentare abgeben. Dabei werden die Pull Requests berücksichtigt, die von Coroid Qualitätskontrolle geprüft wurden.
Coroid Rezension-Einstellungen:
- Was veröffentlicht wird. Die Einstellung „Beratend“, die Standardeinstellung, gibt Kommentare ab und führt nie zu einem Fehler bei der Prüfung – mit einer Ausnahme: Ein bestätigtes kritisches oder hohes Sicherheitsproblem führt zum Fehler, wenn die Sicherheit eine Sicherheitsprüfung verlangt (siehe Code-Scanning und Sicherheitsprüfung). Die Einstellung „Blockierend“ verhindert bei einem Problem die Weiterverarbeitung und macht die Prüfung fehlerhaft. Machen Sie Coroid Rezension zu einer erforderlichen Prüfung in GitHub, damit eine blockierende Rezension das Zusammenführen verhindert.
- Welche Pull Requests. Standardmäßig wartet die Prüfung, bis ein Entwurf als bereit markiert wird, und überspringt Pull Requests, die von Coroid selbst geöffnet wurden, da Coroid's Reviewer diese bereits innerhalb der Aufgabe geprüft hat. Auch Pull Requests von Bots können übersprungen werden.
- Wann die Prüfung erfolgt. Die Prüfung wartet nach dem letzten Push auf eine Ruhephase – standardmäßig fünf Minuten. Ein neuerer Push unterbricht eine noch nicht gestartete Prüfung. Bei einem erneuten Ausführen auf GitHub wird die Prüfung sofort gestartet.
- Rezensionsumfang. Wie viel der Reviewer in einer Prüfung lesen und schreiben darf.
Er folgt den Rezensionsregeln von Coroid sowie den Regeln in Ihrem Repository-
review-rules -Ordner. Ein Projekt, das die Organisationseinstellungen nutzt, erhält die entsprechenden Einstellungen – genauso wie bei jeder anderen Steuerung.
Wenn etwas fehlschlägt
Drei Schalter unter den Organisationseinstellungen wandeln Fehler in Nachbearbeitungsaufgaben für jedes Projekt um. Jeder Schalter steuert eine Automatisierung, die in der Factory unter „Automatisierungen“ aufgelistet ist; der Agent liest den Code und öffnet eine Aufgabe, die anschließend nach denselben Spezifikationen, dem Build-, Verifizierungs- und Rezensionsprozess wie jede andere Aufgabe abläuft.
| Schalter | Wann | Was der Agent tut |
|---|---|---|
| Bei einem fehlgeschlagenen Task wird ein Fix-Task geöffnet | Ein Task schlägt fehl | Der Grund wird ermittelt und, falls er im Code liegt, wird ein Task zur Behebung des Problems geöffnet |
| Bei einem fehlgeschlagenen Deployment wird die Ursache untersucht | Ein Deployment schlägt fehl | Der Agent analysiert die Änderungen in dieser Version und öffnet einen Task, der den Fehler sowie die notwendigen Anpassungen beschreibt |
| Bei einem zurückgerollten Release wird die Behebung geplant | Ein Release wird zurückgerollt | Öffnet eine Aufgabe, die festhält, was zurückgesetzt wurde, warum und welche Änderungen vor dem erneuten Versand nötig sind. |
Wenn man eine Automatisierung deaktiviert, wird ihre Ausführung pausiert; das erneute Aktivieren setzt sie fort. Jede Änderung kann rückgängig gemacht werden. Die Seite der Automatisierung in der Factory gibt an, dass sie von der Qualitätskontrolle verwaltet wird. Die Pause dort entspricht dem Deaktivieren; durch das Ändern der Anweisungen wird die Automatisierung zu Ihrer eigenen – nach Bestätigung lässt sich der Schalter nicht mehr zum Ein- oder Ausschalten nutzen.
Das waren Vorlagen in den Neuen Aufgaben. Eine aus einer davon erstellte Automatisierung läuft weiter. Wenn Sie sie nie geändert haben, übernimmt der entsprechende Schalter die Steuerung statt einer zweiten Instanz zu starten. Haben Sie sie geändert, bleibt sie Ihre eigene: Der Schalter benennt sie entsprechend, und Sie können sie übernehmen, sodass der Schalter sie verwaltet.
Sicheres Ausrollen
Das Problem bei Gates ist nicht, dass sie zu schwach sind – sondern dass ein wohlmeinender blockierender Gate alle Aufgaben der Organisation gleichzeitig stoppt.
Eine sichere Abfolge:
- Fügen Sie den Gate als beratend hinzu.
- Lassen Sie ihn ein bis zwei Wochen lang mit echter Arbeit arbeiten. Lesen Sie, was er meldet.
- Passen Sie ihn anhand dessen an, was Sie erfahren haben.
- Stufen Sie ihn zu blockierend hoch in einem Projekt.
- Rollen Sie ihn breiter aus, sobald er zuverlässig funktioniert.
- 1Prüfpunkt hinzufügenBeratend
- 2Ein bis zwei Wochen beobachtenBeratend
- 3An die gemeldeten Probleme anpassenBeratend
- 4Für ein Projekt blockierend einrichtenBlockierendEin Projekt
- 5Weiter verbreitenBlockierendMehrere Projekte
Versionsverwaltung und Rollback
Richtlinien werden versioniert. Jeder Schalter veröffentlicht eine neue Version – die Bestätigung kann sie durch die Rückkehr zur vorherigen Version rückgängig machen; ältere Versionen lassen sich aus dem Versionsverlauf des erweiterten Editors wiederherstellen.
Rollback ist der Grund, warum Sie beim Veröffentlichen entschlossen handeln können. Ist ein neuer Gate falsch eingestellt, lässt sich dies mit einer einzigen Aktion rückgängig machen – statt aufwendiger Recherchen.
Überschreibungen
Ein blockierender Gate kann von einer berechtigten Person überschrieben werden. Die Überschreibung wird dokumentiert – wer, wann und gegen welche Regel.
Beobachten Sie Ihre Überschreibungsrate. Ein Gate, das bei jeder Auslösung überschrieben wird, setzt nichts durch – es verursacht nur Reibung und einen Papierkram. Entweder korrigieren Sie den Gate oder eliminieren ihn.