Release candidate (RC): co znamená a jak ho vést

Release candidate (RC) je build, o kterém tým věří, že je připravený k vydání. Má kompletní funkce, prošel plánovaným testováním a stane se finálním vydáním beze změny, pokud někdo nenajde chybu dost závažnou na to, aby vydání zablokovala. Označení je příslib o buildu: žádné nové funkce, jen opravy blokujících chyb. Pokud je oprava potřeba, tým vytvoří nového kandidáta a začne odznovu.

Co je release candidate v softwaru?

Je to poslední předvydávací fáze před obecnou dostupností. Myšlenka je, že build je kandidátem na finální verzi a vydání proběhne povýšením téhož buildu, a ne vytvořením nového. Článek na Wikipedii o životním cyklu vydání softwaru popisuje stejnou posloupnost alfa, beta, release candidate a vydání a tyto pojmy jsou široce srozumitelné napříč open source projekty i dodavateli.

Jaký je rozdíl mezi betou a release candidate?

Beta se ještě smí měnit. Funkce lze upravit, rozhraní se mohou přesunout a cílem je zjistit, co chybí nebo je špatně. Release candidate se takto už nemění a cílem je potvrdit, že vydání nic neblokuje. Praktický test je, co tým udělá s hlášením chyby. V betě může hlášení vést ke změně návrhu. V RC vede hlášení k opravě jen tehdy, pokud chyba brání vydání, a vše ostatní jde do fronty na další verzi.

Jak verzovat release candidate?

Použijte příponu předvydání na verzi, kterou se chystáte vydat. Podle Semantic Versioning označuje pomlčka následovaná identifikátory oddělenými tečkami předvydání, takže první kandidát na 2.4.0 je 2.4.0-rc.1, další je 2.4.0-rc.2 a vydání je prosté 2.4.0.

Priorita se řídí specifikací: 2.4.0-rc.1 řadí pod 2.4.0-rc.2 a jakékoli předvydání řadí pod vydání. Protože se identifikátory porovnávají jeden po druhém a čísla číselně, rc.10 řadí nad rc.9. Názvy alpha, beta a rc se navíc abecedně řadí ve správném pořadí, což je jeden z důvodů, proč je týmy používají. Každého kandidáta označte tagem v gitu, jak popisuje článek o git tazích a vydáních, aby byl zaznamenaný přesný commit.

Jaká jsou kritéria ukončení pro release candidate?

Sepište je dřív, než vznikne první RC. Použitelná sada:

• Automatizované testy procházejí na přesném commitu, ze kterého byl build vytvořen.
• Cesta upgradu z předchozího vydání byla otestována na realistických datech.
• Známé problémy jsou roztříděné a žádný není hodnocen jako blokující.
• Výkon a míra chyb odpovídají předchozímu vydání v dohodnuté toleranci.
• Release notes jsou napsané a zkontrolované proti finálnímu seznamu změn.
• Existuje cesta zpět (rollback) a někdo si ji přečetl.

Když platí každý řádek pro jednoho kandidáta, ten kandidát je vydání. Pokud některý řádek selže, oprava vytvoří nového kandidáta a kontroly začnou znovu. Sedmikrokovou verzi tohoto postupu s vlastníky jednotlivých kroků najdete v článku proces správy vydání.

Co udělat s buildem, když RC projde?

Povyšte tentýž artefakt. Nestavějte znovu z tagu, protože nový build může natáhnout jinou závislost nebo výstup kompilátoru a testování, které jste provedli, platilo pro původní build. Mnoho týmů kandidáta přejmenuje novým tagem nebo přepnutím štítku v registru, takže bajty, které se testovaly, jsou bajty, které uživatelé stahují.

U balíčků publikujte kandidáty v samostatném kanálu, aby je běžní uživatelé nedostali omylem. S npm příkaz npm publish --tag rc nechá výchozí tag latest tam, kde byl, a kandidáta dostanou jen ti, kdo si řeknou o @rc. Kontejnerové image a mobilní buildy mají stejnou myšlenku pod jinými názvy: tag předvydání, postupné nasazení nebo kanál ve stylu TestFlightu.

Jak napsat release notes pro release candidate?

Začněte psát poznámky u prvního RC a držte je v souladu s kandidáty. Testeři potřebují vědět, co se změnilo, co zkontrolovat a co je známo jako rozbité, a psaní od začátku odhalí položky, na které si na konci nikdo nevzpomene. Stránku nebo GitHub release označte jako předvydání, aby ji nikdo nezaměnil za finální verzi, a hotový text přesuňte do GA vydání, až vyjde. Rozvržení a obsah jsou v článku release notes softwaru a stranu GitHubu popisuje GitHub release notes.

Potřebují týmy SaaS release candidate?

Týmy, které nasazují průběžně, je potřebují zřídka, protože nasazení do produkce je test a o tom, kdo změnu uvidí, rozhoduje feature flag. Release candidate si své místo získá tam, kde si uživatelé software instalují sami a nelze ho vrátit nasazením: knihovny, desktopové a mobilní aplikace, self-hosted produkty a API s dlouhodobými klienty. U hostovaného produktu, který změny zpřístupňuje postupně, je ekvivalentem postupné nasazení, které z pohledu komunikace pokrývá článek o release notes pro feature flag.

FAQ

Co znamená RC v softwaru? RC je zkratka pro release candidate. Je to build, který tým zamýšlí vydat jako finální verzi, pokud testování nenajde blokující chybu. Následuje po fázích alfa a beta a předchází obecné dostupnosti.

Je release candidate dost stabilní pro produkci? Obvykle ano pro testování ve stagingu nebo v omezeném produkčním provozu a nese riziko, které finální vydání nemá, protože testování nemusí být dokončené. Berte ho jako kód v produkční kvalitě, který je ještě ve zkušební lhůtě.

Kolik release candidate by mělo mít jedno vydání? Tolik, kolik je potřeba, a většina vydání jich potřebuje jeden až tři. Dlouhá řada kandidátů obvykle znamená, že zmrazení bylo vyhlášeno příliš brzy nebo že pokrytí testy zachytává chyby pozdě.

Může se release candidate stát finálním vydáním beze změn? Ano, a je to zamýšlený výsledek. Finální vydání má být tentýž build jako poslední kandidát, jen přejmenovaný nebo označený jako GA.

Technická tvrzení v tomto článku nikdo nezávisle neověřil. Pokud tu něco nesedí, dej nám vědět a opravíme to.

Související na changeloop: Dokumentace pro vývojáře, Šablona poznámek k vydání