Release Candidate (RC): Bedeutung und wie man einen fährt

Ein Release Candidate (RC) ist ein Build, den das Team für auslieferungsreif hält. Er ist funktional vollständig, hat die geplanten Tests bestanden und wird unverändert zum finalen Release, es sei denn, jemand findet einen Fehler, der schwer genug ist, ihn zu blockieren. Das Etikett ist ein Versprechen über den Build: keine neuen Features, nur Fixes für Blocker. Wird ein Fix nötig, schneidet das Team einen neuen Kandidaten und startet die Uhr von vorn.

Was ist ein Release Candidate in der Softwareentwicklung?

Er ist die letzte Vorabversion vor der allgemeinen Verfügbarkeit. Die Idee ist, dass der Build ein Kandidat für die finale Version ist und das Release stattfindet, indem genau dieser Build befördert wird, statt einen neuen zu bauen. Der Wikipedia-Artikel zum Software-Release-Zyklus beschreibt dieselbe Abfolge aus Alpha, Beta, Release Candidate und Release, und die Begriffe sind in Open-Source-Projekten und bei Herstellern weithin verstanden.

Was ist der Unterschied zwischen Beta und Release Candidate?

Eine Beta darf sich noch ändern. Features können angepasst werden, Schnittstellen können sich verschieben, und das Ziel ist zu lernen, was fehlt oder falsch ist. Ein Release Candidate ändert sich so nicht mehr, und das Ziel ist zu bestätigen, dass nichts das Release blockiert. Der praktische Test ist, was das Team mit einem Fehlerbericht macht. In einer Beta kann ein Bericht zu einer Designänderung führen. In einem RC führt ein Bericht nur dann zu einem Fix, wenn der Bug das Ausliefern blockiert, und alles andere wandert in die Warteschlange für die nächste Version.

Wie versioniert man einen Release Candidate?

Man hängt ein Pre-Release-Suffix an die Version, die ausgeliefert werden soll. Nach Semantic Versioning kennzeichnet ein Bindestrich gefolgt von durch Punkte getrennten Bezeichnern eine Vorabversion, also ist der erste Kandidat für 2.4.0 2.4.0-rc.1, der nächste 2.4.0-rc.2, und das Release ist schlicht 2.4.0.

Die Rangfolge richtet sich nach der Spezifikation: 2.4.0-rc.1 sortiert unter 2.4.0-rc.2, und jede Vorabversion sortiert unter dem Release. Weil Bezeichner einzeln verglichen werden und Zahlen numerisch, sortiert rc.10 über rc.9. Die Namen alpha, beta und rc sortieren außerdem alphabetisch in der richtigen Reihenfolge, was mit ein Grund ist, warum Teams sie verwenden. Jeder Kandidat wird in git getaggt, wie in Git-Tags, Releases und dein Changelog beschrieben, damit der genaue Commit festgehalten ist.

Was sind die Ausstiegskriterien für einen Release Candidate?

Sie werden aufgeschrieben, bevor der erste RC geschnitten wird. Ein brauchbarer Satz:

• Die automatisierte Testsuite läuft auf genau dem Commit durch, der gebaut wurde.
• Der Upgrade-Pfad vom vorherigen Release wurde mit realistischen Daten getestet.
• Bekannte Probleme sind eingestuft, und keines gilt als Blocker.
• Performance und Fehlerraten entsprechen dem vorherigen Release innerhalb einer vereinbarten Spanne.
• Die Release Notes sind entworfen und gegen die endgültige Liste der Änderungen geprüft.
• Ein Rollback-Pfad existiert, und jemand hat ihn gelesen.

Stimmt jede Zeile für einen Kandidaten, ist dieser Kandidat das Release. Fällt eine Zeile durch, erzeugt der Fix einen neuen Kandidaten, und die Prüfungen beginnen von vorn. Die siebenstufige Fassung dieses Ablaufs, mit Verantwortlichen für jeden Schritt, steht im Release-Management-Prozess.

Was tut man mit dem Build, wenn ein RC besteht?

Man befördert dasselbe Artefakt. Es wird nicht aus dem Tag neu gebaut, weil ein Neubau eine andere Abhängigkeit oder eine andere Compiler-Ausgabe hereinziehen kann und die durchgeführten Tests für den ursprünglichen Build galten. Viele Teams benennen den Kandidaten um, indem sie neu taggen oder ein Registry-Label umhängen, damit die getesteten Bytes die Bytes sind, die Nutzer herunterladen.

Bei Paketen werden Kandidaten in einem eigenen Kanal veröffentlicht, damit normale Nutzer sie nicht versehentlich bekommen. Mit npm lässt npm publish --tag rc das Standard-Tag latest dort, wo es war, und nur wer @rc anfordert, bekommt den Kandidaten. Container-Images und Mobile-Builds kennen dieselbe Idee unter anderen Namen: ein Pre-Release-Tag, einen gestaffelten Rollout oder eine Spur im Stil von TestFlight.

Wie schreibt man Release Notes für einen Release Candidate?

Die Notes beginnen beim ersten RC und werden mit den Kandidaten synchron gehalten. Tester müssen wissen, was sich geändert hat, was zu prüfen ist und was bekanntermaßen kaputt ist, und frühes Entwerfen findet die Einträge, an die sich am Ende niemand erinnert. Die Seite oder das GitHub-Release wird als Pre-Release markiert, damit niemand sie mit der finalen Version verwechselt, und der fertige Text zieht beim Ausliefern ins GA-Release um. Aufbau und Inhalt stehen in Software-Release-Notes, und die GitHub-Seite in GitHub-Release-Notes.

Brauchen SaaS-Teams Release Candidates?

Teams, die kontinuierlich ausrollen, brauchen sie selten, denn das Produktions-Deployment ist der Test und ein Feature Flag steuert, wer eine Änderung sieht. Release Candidates lohnen sich, wenn Nutzer die Software selbst installieren und sich nicht per Deployment zurückrollen lassen: Bibliotheken, Desktop- und Mobile-Apps, selbst gehostete Produkte und APIs mit langlebigen Clients. Bei einem gehosteten Produkt, das Änderungen schrittweise freigibt, ist das Gegenstück ein gestaffelter Rollout, den der Artikel über Feature-Flag-Release-Notes von der Kommunikationsseite her behandelt.

FAQ

Was bedeutet RC in der Software? RC steht für Release Candidate. Es ist ein Build, den das Team als finale Version ausliefern will, wenn die Tests keinen blockierenden Bug finden. Er folgt auf Alpha und Beta und steht vor der allgemeinen Verfügbarkeit.

Ist ein Release Candidate stabil genug für die Produktion? Meist ja für Tests in Staging oder in begrenztem Produktionsbetrieb, und er trägt ein Risiko, das das finale Release nicht hat, weil die Tests womöglich nicht abgeschlossen sind. Er ist Produktionscode auf Bewährung.

Wie viele Release Candidates sollte ein Release haben? So viele wie nötig, und die meisten Releases brauchen einen bis drei. Eine lange Reihe von Kandidaten bedeutet meist, dass der Freeze zu früh ausgerufen wurde oder die Testabdeckung Dinge spät findet.

Kann ein Release Candidate ohne Änderungen zum finalen Release werden? Ja, und das ist das gewünschte Ergebnis. Das finale Release sollte derselbe Build wie der letzte Kandidat sein, nur umbenannt oder als GA gekennzeichnet.

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.

Mehr bei changeloop: Entwicklerdokumentation, Vorlage für Release Notes