Coroid modelliert einen vollständigen Software-Lebenszyklus und nicht nur den Build-Schritt. Der Großteil davon läuft automatisch; ein Teil ist ein optionaler Prüfpunkt, den Sie aktivieren, wenn die zu erledigende Aufgabe wichtig genug ist.
Der optionale SDLC-Workflow
Im Neue Aufgaben Formular, unter erweiterten Einstellungen, befindet sich ein Kontrollkästchen:
SDLC-Workflow nutzen (optional) — eine Absichts- und Spezifikationsprüfung vor der Planung. Deaktivieren Sie diese Option, um direkt mit der Planung basierend auf Ihrer Beschreibung zu beginnen.
Er ist standardmäßig deaktiviert. Bei deaktivierter Option beginnt die Planung sobald Ihre Beschreibung die Qualifikation durchläuft. QualifikationWenn aktiviert, werden zuerst zwei Artefakte erstellt und freigegeben:
- Absicht — der eigentliche Zweck der Arbeit, samt den zugrunde liegenden Entscheidungen und Annahmen.
- Spezifikation — Umfang, Ausnahmen und Akzeptanzkriterien.
Erst nach deren Freigabe beginnt die Planung.
Wann sollten Sie ihn aktivieren?
Aktivieren Sie ihn, wenn die Kosten für die Entwicklung des Falschen hoch sind, wenn die Anfrage von jemandem stammt, der den Plan selbst nicht prüfen wird, oder wenn die Beschreibung eine Annahme enthält, die Sie schriftlich festgehalten und abgestimmt sehen möchten.
Deaktivieren Sie ihn, wenn die Beschreibung bereits eindeutig ist. Eine zusätzliche Freigabeschranke bei Routineaufgaben erzeugt unnötigen Aufwand – und die Planungsfreigabe gilt trotzdem in jedem Fall. Planungsfreigabe Schritt bleibt in jedem Fall bestehen.
Die fünf Stationen
Der vollständige Lebenszyklus besteht aus fünf Phasen, wobei jede Phase Nachweise für die nächste Phase liefert.
| Station | Was geschieht? | Status |
|---|---|---|
| Definieren | Eine mehrdeutige Anfrage wird zu einer genehmigten Absicht, zu Entscheidungen, Annahmen und Erfolgsmaßen. | Beta |
| Visualisieren | Optionale UI-Konzepte werden weiter ausgearbeitet und als Designrichtlinien freigegeben. | Beta |
| Ausführen | Der Plan wird aufgeschlüsselt und von Agenten ausgeführt. | Verfügbar |
| Nachweisen | Anforderungen werden in Aufgaben, Prüfungen, Review-Ergebnisse und Pull-Request-Änderungen übersetzt. | Verfügbar |
| Verbessern | Überwachung, Behebung und Bewertung wandeln Regressionsfehler in die Arbeit des nächsten Zyklus um. | Verfügbar |
- DefinierenGenehmigte Absicht, Entscheidungen, Annahmen und ErfolgskriterienBeta
- VisualisierenOptionale UI-Konzepte, als Designrichtlinien genehmigtBeta
- LiefernDer Plan wird aufgeschlüsselt und von Agenten ausgeführtVerfügbar
- NachweisenAnforderungen werden in Aufgaben, Prüfungen, Feststellungen und Änderungen umgewandeltVerfügbar
- VerbessernRegressionsprobleme werden zur Arbeit des nächsten ZyklusVerfügbar
OptionalAktivieren Sie den SDLC-Workflow, um Absicht und Spezifikation vor Beginn der Planung zu genehmigen.
Verbessern speist den nächsten Zyklus: Überwachung, Behebung und Bewertung wandeln Regressionsprobleme in neue Aufgaben um.
Definieren und Visualisieren befinden sich derzeit in der aktiven Entwicklung. Liefern, Nachweisen und Verbessern laufen bereits bei jeder Aufgabe – unabhängig davon, ob Sie den Prüfpunkt aktivieren oder nicht.
Warum die Artefakte versioniert werden
Freigaben beziehen sich auf eine exakte Version eines Artefakts. Die Bearbeitung eines freigegebenen Artefakts erzeugt einen neuen Entwurf, anstatt das zuvor Vereinbarte stillschweigend zu ändern.
Genau das macht eine Freigabe bedeutsam. Eine Freigabe, die nicht an eine bestimmte Version gebunden ist, sondern an die „Spezifikation“ selbst, gilt für den jeweiligen Wortlaut des Dokuments – das ist keine echte Freigabe.
Freigabepapiere
Die Verantwortlichkeiten für Produkt, Design, Technik, Sicherheit und Releases können unabhängig voneinander zugewiesen werden. Somit muss die Person, die die Sicherheitsauswirkungen prüft, nicht zwingend auch die Person sein, die den Umfang freigibt.
Nachvollziehbarkeit der Belege
Der Zweck der Erstellung von Belegen an jedem Schritt besteht darin, dass ein fertiges pull request rückverfolgt werden kann: Diese Änderung implementiert diese Aufgabe, die wiederum aus dieser Anforderung resultiert, welche wiederum auf dieser genehmigten Absicht beruht.
Diese Kette macht die autonome Lieferung nachvollziehbar. Ohne sie hätten Sie funktionierenden Code – aber keine Erklärung dafür, warum es genau der gewünschte Code ist.
Vom überprüften Code zur Release
pull request ist das Ergebnis des Arbeitszyklus. Sobald Ihre Repository-Regeln ein Mergen erlauben, wird eine Release speichert den vollständigen Commit-SHA und dokumentiert, welche Änderungen dieser Commit enthält. Die Bereitschaftsschranke prüft genau diesen Commit für eine ausgewählte Umgebung. Freigaben beziehen sich auf den Snapshot der Schranke; die Bearbeitung des Kandidaten oder der Richtlinie macht frühere Entscheidungen ungültig.
Die Anforderung einer Deployment-Ausführung startet einen Versuch in Ihrer verbundenen Pipeline. Ein Provider-Rückruf oder eine manuelle Bestätigung protokolliert, was eine Umgebung erreicht hat, und ein post-deploy-Canary erfasst die Systemgesundheit separat. Die Aufgabe, pull request und Release haben daher unterschiedliche Bedeutungen: Fertiggestellte Arbeit beweist nicht, dass der Code bereits in Produktion ist.
Wie dies mit Plänen zusammenhängt
Der SDLC-Workflow und Pläne sind unterschiedliche Prüfpunkte:
- Der SDLC-Workflow genehmigt was gebaut werden soll, noch bevor ein konkreter Ansatz existiert.
- Der Plan genehmigt wie es gebaut wird, noch bevor Code existiert.
Sie können einen, beide oder keinen davon nutzen. Beide Varianten sind kostengünstiger als die Überprüfung eines fertigen pull request, mit dem Sie nicht einverstanden sind.