Eine Richtlinie ist ein benannter, versionsgebundener Satz von Qualitätskriterien. Richtlinien werden Projekten zugeordnet; die Kriterien sind es, die tatsächlich ausgeführt werden.
Zu den Konzepten – blockierend vs. beratend, wo die Kriterien im Ablauf platziert sind – lesen Sie Qualitätskriterien zuerst. Diese Seite behandelt die Verwaltung davon.
Verwalten Sie sie in Qualitätskontrolle. Die Liste zeigt die Organisationseinstellung und alle Projekte an. Wählen Sie eines aus, um zu sehen, wie neue Arbeit geprüft wird, welche Überprüfungen bei jeder Änderung stattfinden, welches QA-Niveau verwendet wird und wo die Prüfungen ausgeführt werden; jede Einstellung lässt sich per Schalter sofort aktivieren. Die Bestätigung ermöglicht das Rückgängigmachen der Änderung, und die Einstellungen einer Zeile bestimmen, wie die jeweilige Prüfung funktioniert.
- 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 blockiert oder nur beratend wirkt.
Die meisten Organisationen benötigen zwei oder drei Richtlinien, nicht eine pro Projekt:
- eine strenge Richtlinie für Produktivsysteme
- eine Standard- Richtlinie für den normalen Betrieb
- gelegentlich eine leichte Richtlinie für interne Tools und Prototypen
Mehr als das kann niemand mehr nachvollziehen, welches Projekt welche Richtlinie hat.
Die Organisationseinstellung und die individuelle Konfiguration eines Projekts
Ein Projekt folgt der Organisationseinstellung, bis Sie einen der Schalter ändern. Diese Änderung erzeugt eine eigene Konfiguration des Projekts, die von der Standardeinstellung übernommen wird; spätere Änderungen an der Standardeinstellung wirken sich dann nicht mehr darauf aus. Eine Zeile kann eine Prüfung aus der Standardeinstellung übernehmen, und das Projektmenü kann das gesamte Projekt auf die Organisationseinstellung zurücksetzen. Die vollständige Richtlinie hinter den Schaltern – mit Erwartungen, Abhängigkeiten zwischen Prüfungen, Reparaturbudgets und Versionen – öffnet sich über dasselbe Menü wie der erweiterte Editor. Bei einem Projekt, das der Standardeinstellung folgt, startet der Editor mit einer Kopie davon, und nichts ändert sich für das Projekt, bis Sie diese Kopie veröffentlichen.
Setzen Sie die Standardeinstellung auf Ihre Standard- Prüfungen, die die meisten Projekte durchführen sollten – nicht die strengsten; die strengsten müssen gezielt, projektweise aktiviert werden.
Pull Requests
Pull Requests, die von Personen und anderen Tools geöffnet werden, gelangen über die Coroid GitHub App zu Coroid. Die Pull Requests Gruppe in der Qualitätskontrolle entscheidet, was damit geschieht – für die Organisationseinstellung und für jedes Projekt:
- Coroid Qualitätskontrolle führt die oben genannten Prüfungen bei jedem pull request aus und meldet das Ergebnis als Coroid Qualitätskontroll-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. Beratend – die Standardeinstellung – gibt Kommentare ab und lässt die Prüfung nie scheitern. Beim Blockieren wird bei einem Problem die Anfrage gestoppt und die Prüfung scheitert. Machen Sie Coroid Rezension zu einer erforderlichen Prüfung in GitHub, wenn eine blockierende Rezension das Zusammenführen verhindern soll.
- Welche Pull Requests. Standardmäßig wartet die Rezension, bis ein Entwurf als bereit gekennzeichnet ist, und überspringt Pull Requests, die von Coroid selbst geöffnet wurden – schließlich hat Coroid's Reviewer sie bereits innerhalb der Aufgabe geprüft. Auch Pull Requests von Bots können übersprungen werden.
- Wann die Rezension stattfindet. Die Rezension wartet auf eine Ruhephase nach dem letzten Push – standardmäßig fünf Minuten. Ein neuerer Push unterbricht eine noch nicht begonnene Rezension. Bei einem erneuten Ausführen auf GitHub startet die Rezension sofort.
- Rezensionsumfang. Wie viel darf der Reviewer in einer Rezension lesen und schreiben.
Er folgt den Rezensionsregeln von Coroid sowie den Regeln in Ihrem Repository-
review-rules Ordner. Ein Projekt, das der Organisationseinstellung folgt, übernimmt deren Einstellungen, genau wie bei allen anderen Steuerungen.
Wenn etwas fehlschlägt
Drei Schalter unter der Organisationseinstellung wandeln Fehler in Nacharbeit 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 derselben Spezifikation, dem gleichen Build-, Verifizierungs- und Rezensionsprozess wie jede andere Aufgabe abläuft.
| Schalter | Wann | Was der Agent tut |
|---|---|---|
| Bei einem fehlgeschlagenen Task eine Korrekturaufgabe öffnen | Ein Task schlägt fehl | Der Grund wird ermittelt; liegt der Fehler im Code, wird eine Aufgabe zur Behebung des Problems erstellt. |
| Bei einem fehlgeschlagenen Deployment die Ursache untersuchen | Ein Deployment schlägt fehl | Es wird geprüft, was sich in dieser Version geändert hat, und eine Aufgabe wird erstellt, die den Fehler sowie die notwendigen Änderungen beschreibt. |
| Bei einem Rollback einer Releaseversion die Korrektur planen | Eine Releaseversion wird zurückgerollt | Es wird eine Aufgabe erstellt, die festhält, was zurückgerollt wurde, warum und welche Änderungen vor einem erneuten Versand nötig sind. |
Wenn Sie eine Automatisierung deaktivieren, wird sie 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. Dort die Automatisierung zu pausieren entspricht dem Deaktivieren; nach Bestätigung der neuen Anweisungen wird die Automatisierung individuell angepasst und der Schalter kann sie nicht mehr einfach ein- oder ausschalten.
Diese waren Vorlagen in Neue Aufgaben. Eine daraus erstellte Automatisierung läuft weiter. Falls Sie sie nie geändert haben, übernimmt der zugehörige Schalter die Steuerung statt einer zweiten Instanz zu starten. Haben Sie sie jedoch angepasst, bleibt sie Ihnen vorbehalten: Der Schalter trägt ihren Namen und Sie können sie übernehmen, sodass der Schalter sie verwaltet.
Sichere Ausrollung
Das Problem bei Gates besteht nicht darin, dass sie zu schwach sind, sondern darin, dass ein wohlmeinender blockierender Gate alle Aufgaben der Organisation gleichzeitig stoppt.
Eine sichere Abfolge:
- Fügen Sie den Gate als beratend.
- Lassen Sie ihn ein bis zwei Wochen lang in der Praxis laufen und lesen Sie, welche Hinweise er liefert.
- Passen Sie ihn anhand der gewonnenen Erkenntnisse an.
- Befördern Sie ihn zu blockierend in einem Projekt.
- Sobald er zuverlässig funktioniert, rollen Sie ihn weiter aus.
- 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 Rückkehr zur vorherigen Version rückgängig machen. Ältere Versionen lassen sich über den Versionsverlauf des erweiterten Editors wiederherstellen.
Rollback ist der Grund, warum Sie beim Veröffentlichen entschlossen vorgehen können. Ist ein neuer Gate falsch eingestellt, lässt sich dies mit einer einzigen Aktion rückgängig machen – ohne aufwendige Recherchen.
Überschreibungen
Ein blockierender Gate kann von einer berechtigten Person überschrieben werden. Die Überschreibung wird protokolliert – wer, wann und gegen welche Regel.
Beobachten Sie Ihre Überschreibungsrate. Ein Gate, das bei jedem Auslösen überschrieben wird, setzt nichts durch, sondern verursacht nur Reibung und Papierkram. Entweder den Gate korrigieren oder ihn entfernen.