9 Regeln
Dokumentation
README vorhanden und mindestens 500 Zeichen, eine erkannte LICENSE (bei öffentlichen Repositorys), CHANGELOG, CONTRIBUTING, ein Designabschnitt in architecture.md.
Seien Sie mit einem einzigen Bericht auditbereit.
Compliance prüft jedes Repository anhand einer Checkliste mit 36 Regeln: Dokumentation, Repository-Hygiene, Sicherheit, CI und Integration. Jeder Scan liefert einen gewichteten Score und eine Ergebnisliste für den Auditor.
Bildschirme aus einer laufenden Installation
36 Regeln in fünf Kategorien
Compliance betrachtet, was ein Repository enthält und wie es eingerichtet ist, nicht die Logik des Codes. Jede Regel ist eine Ja-Nein-Frage mit einem Schweregrad.
12 Regeln
Repository-Hygiene
.gitignore und .editorconfig, Beschreibung und Topics, main oder master als Standardbranch, nicht archiviert; bei Backends ein mehrstufiges Dockerfile und ein lokales docker-compose.
7 Regeln
Sicherheit
Eine Sicherheitsrichtlinie, automatische Abhängigkeitsupdates, eine .env.example, Container ohne Root-Benutzer, Basis-Images aus erlaubten Registries, NuGet nur aus erlaubten Feeds.
5 Regeln
Continuous Integration
Ein CI-Workflow existiert und führt die Tests aus, ein Build-Badge im README, ein Lint-Skript für Frontends, Fastlane für mobile Apps.
3 Regeln
Integration
Die Git-Anmeldedaten des Projekts sind gültig, ArchPilot hat kürzlich einen Merge Request geprüft, der Workspace hat einen Benachrichtigungskanal.
Welche Regeln für welches Projekt gelten
Ein Frontend hat kein Dockerfile zu prüfen, eine mobile App keine robots.txt. Sie wählen die Stacks jedes Projekts; universelle und Integrationsregeln gelten immer.
Eine fehlende Antwort ist kein Fehlschlag
Jedes Regelergebnis ist bestanden, fehlgeschlagen, übersprungen oder Fehler. Nur bestanden und fehlgeschlagen zählen, nach Schweregrad gewichtet; eine nicht beantwortbare Regel fällt aus dem Nenner, statt den Score zu drücken.
- Erforderlich×2
- Empfohlen×1
- Optional×0.5
- Bestanden · zählt
- Fehlgeschlagen · zählt
- Übersprungen · bleibt außen vor
- Fehler · bleibt außen vor
Warum so: Ein abgebrochenes VPN ließ einmal jedes Projekt 6/100 anzeigen. Ein unerreichbarer Git-Server sagt nichts über das Repository aus, also zählt er nicht mehr.
Wie ein Scan abläuft
-
Ausgelöst
Von Hand oder per täglichem oder wöchentlichem Zeitplan für eine Projektgruppe oder eine Projektliste.
-
In der Warteschlange
Ein Worker übernimmt ihn binnen Sekunden; der Scan vermerkt, wer oder was ihn ausgelöst hat.
-
Regeln beantwortet
Dateien, Repository-Einstellungen und Branch-Schutz werden beim Git-Anbieter gelesen; nichts wird geklont.
-
Bewertet und gespeichert
Der Score geht in die Historie und Gesundheitskarte des Projekts ein, und in die Digest-E-Mail, wenn Sie sie abonnieren.
Regeln werden auf drei Ebenen ein- oder ausgeschaltet: Installationsstandard, Workspace und Projekt. Die engste Einstellung gewinnt.
So sieht es im Produkt aus
Alle Screenshots
Gehen Sie vorbereitet in Ihr nächstes Audit
Wählen Sie den Stack jedes Projekts, aktivieren Sie die gewünschten Regeln, planen Sie die Scans; der Score bleibt aktuell, ohne dass jemand daran denken muss.