Eine Release gruppiert die erbrachte Arbeit zu etwas, das Sie benennen und beschreiben können. Während Aufgaben, Pläne und Sprints die laufende Arbeit organisieren, ordnet eine Release die fertiggestellte Arbeit.
Sie finden sie unter Releases.
Zweck einer Release
Beantwortung der Frage „Was wurde ausgeliefert?“ – für Release-Notes, für Stakeholder und für Ihre eigene Dokumentation zum Zeitpunkt von Änderungen.
Coroid verfolgt die Arbeit auf Aufgabenebene – das ist die richtige Granularität für die Ausführung, aber die falsche für die Kommunikation. Niemand möchte eine Liste mit vierzig Aufgaben-Titeln sehen. In einer Release werden diese zu einer kohärenten Aussage zusammengefasst.
Eine Release erstellen
Erstellen Sie eine Release und weisen Sie die darin enthaltene erbrachte Arbeit zu. Die Arbeit muss bereits vorhanden sein, um einbezogen zu werden – eine Release beschreibt, was geschehen ist, nicht was noch geplant ist.
Releases und Ihr Deployments-Prozess
Eine Coroid-Release ist ein Protokoll, kein Deployments-Mechanismus. Sie erstellt keine Artefakte, taggt Ihr Repository nicht oder sendet nichts an eine Umgebung – Ihr bestehender Pipeline-Prozess übernimmt das alles bei Merges, wie bisher üblich.
Diese Trennung ist beabsichtigt. Coroid öffnet Pull Requests; was nach dem Mergen passiert, liegt in Ihrem Prozess. Die Einführung einer zweiten Deployments-Autorität würde genau jene Unklarheiten schaffen, die Sie am Release-Tag vermeiden wollen.
Beziehung zu Sprints
Ein Sprint ist ein Zeitraum; eine Release ist eine Auslieferung. Sie stimmen oft überein, aber ebenso oft nicht – die Arbeit eines Sprints kann über zwei Releases verteilt werden, und eine Release kann Arbeit aus mehreren Sprints zusammenfassen.
Verwenden Sie das, was in Ihrer Organisation tatsächlich kommuniziert wird. Die Nutzung beider Begriffe nur weil sie existieren, führt meist zu unnötigem Verwaltungsaufwand.