Release candidate (RC): ce înseamnă și cum îl rulezi
5 min de citit
Un release candidate (RC) este un build pe care echipa îl consideră gata de livrare. Are toate funcționalitățile, a trecut testele planificate și devine lansarea finală neschimbat, cu excepția cazului în care cineva găsește o eroare suficient de gravă ca să-l blocheze. Eticheta este o promisiune despre build: nicio funcționalitate nouă, doar remedieri pentru blocaje. Dacă e nevoie de o remediere, echipa taie un nou candidat și pornește ceasul de la capăt.
| Etapă | Funcționalități | Public | Stare așteptată |
|---|---|---|---|
| Alpha | Încă se adaugă | Echipa internă | Incompletă, multe erori cunoscute |
| Beta | Complete sau aproape | Voluntari și clienți selectați | Utilizabilă, erorile sunt de așteptat |
| Release candidate | Înghețate | Testeri și early adopters | Considerată gata, se remediază doar blocajele |
| Disponibilitate generală (GA) | Înghețate | Toată lumea | Același build ca ultimul RC |
Ce este un release candidate în software?
Este ultima etapă de pre-lansare înainte de disponibilitatea generală. Ideea e că buildul este un candidat pentru versiunea finală, iar lansarea se face promovând exact acel build, nu făcând unul nou. Articolul Wikipedia despre ciclul de viață al lansărilor software descrie aceeași succesiune de alpha, beta, release candidate și lansare, iar termenii sunt înțeleși pe scară largă în proiectele open source și la furnizori.
Care este diferența dintre beta și release candidate?
O versiune beta mai are voie să se schimbe. Funcționalitățile pot fi ajustate, interfețele se pot muta, iar scopul este să afli ce lipsește sau ce e greșit. Un release candidate a încetat să se schimbe în aceste feluri, iar scopul este să confirmi că nimic nu blochează lansarea. Testul practic este ce face echipa cu un raport de eroare. La beta, un raport poate duce la o schimbare de design. La RC, un raport duce la o remediere doar dacă eroarea blochează livrarea, iar restul se pune la coadă pentru versiunea următoare.
Cum versionezi un release candidate?
Folosește un sufix de pre-lansare pe versiunea pe care urmează s-o livrezi. Conform Semantic Versioning, o cratimă urmată de identificatori separați prin puncte marchează o pre-lansare, deci primul candidat pentru 2.4.0 este 2.4.0-rc.1, următorul este 2.4.0-rc.2, iar lansarea este simplu 2.4.0.
Precedența urmează specificația: 2.4.0-rc.1 se ordonează sub 2.4.0-rc.2, iar orice pre-lansare se ordonează sub lansare. Pentru că identificatorii se compară unul câte unul, iar numerele se compară numeric, rc.10 se ordonează peste rc.9. Numele alpha, beta și rc se ordonează și alfabetic în ordinea corectă, ceea ce e parte din motivul pentru care echipele le folosesc. Etichetează fiecare candidat în git, așa cum este descris în tag-uri git și lansări, ca să fie înregistrat commitul exact.
Care sunt criteriile de ieșire pentru un release candidate?
Scrie-le înainte de a tăia primul RC. Un set care funcționează:
- Suita de teste automate trece pe commitul exact care a fost construit.
- Calea de upgrade de la lansarea anterioară a fost testată cu date realiste.
- Problemele cunoscute sunt triate și niciuna nu este considerată blocaj.
- Performanța și ratele de eroare se potrivesc cu lansarea anterioară într-o marjă convenită.
- Release notes sunt redactate și verificate față de lista finală de modificări.
- Există o cale de rollback și cineva a citit-o.
Când fiecare linie este adevărată pentru un candidat, acel candidat este lansarea. Dacă o linie pică, remedierea produce un nou candidat și verificările o iau de la capăt. Versiunea în șapte pași a acestui flux, cu responsabili pentru fiecare pas, se află în procesul de gestionare a lansărilor.
Ce faci cu buildul când un RC trece?
Promovează același artefact. Nu reconstrui din tag, pentru că o reconstruire poate aduce altă dependență sau altă ieșire a compilatorului, iar testarea făcută s-a aplicat buildului original. Multe echipe redenumesc candidatul prin re-etichetare sau prin repunctarea unei etichete din registry, astfel încât octeții testați să fie cei pe care îi descarcă utilizatorii.
Pentru pachete, publică candidații pe un canal separat, ca utilizatorii obișnuiți să nu-i primească din greșeală. Cu npm, npm publish --tag rc lasă eticheta implicită latest unde era, iar candidatul îl primesc doar cei care cer @rc. Imaginile de container și buildurile mobile au aceeași idee sub alte nume: o etichetă de pre-lansare, un rollout etapizat sau un canal în stil TestFlight.
Cum scrii release notes pentru un release candidate?
Începe notele de la primul RC și ține-le în pas cu candidații. Testerii trebuie să știe ce s-a schimbat, ce să verifice și ce este cunoscut ca defect, iar redactarea timpurie găsește intrările pe care nu și le mai amintește nimeni la final. Marchează pagina sau lansarea GitHub drept pre-lansare, ca nimeni să n-o confunde cu versiunea finală, și mută textul terminat în lansarea GA când aceasta apare. Structura și conținutul sunt în release notes software, iar partea de GitHub este în GitHub release notes.
Au echipele SaaS nevoie de release candidates?
Echipele care livrează continuu rareori au, pentru că deployul în producție este testul, iar un feature flag controlează cine vede o schimbare. Release candidates își merită locul când utilizatorii instalează singuri software-ul și nu pot fi readuși la versiunea anterioară printr-un deploy: biblioteci, aplicații desktop și mobile, produse self-hosted și API-uri cu clienți de lungă durată. Pentru un produs găzduit care expune schimbările treptat, echivalentul este un rollout etapizat, pe care articolul despre note de lansare pentru feature flag-uri îl tratează din perspectiva comunicării.
FAQ
Ce înseamnă RC în software? RC vine de la release candidate. Este un build pe care echipa intenționează să-l livreze ca versiune finală, dacă testarea nu găsește o eroare blocantă. Urmează etapelor alpha și beta și precede disponibilitatea generală.
Este un release candidate suficient de stabil pentru producție? De obicei da, pentru testare într-un mediu de staging sau într-o producție limitată, și poartă un risc pe care lansarea finală nu îl are, pentru că testarea poate să nu fie terminată. Tratează-l ca pe cod de calitate de producție aflat încă în probă.
Câte release candidates ar trebui să aibă o lansare? Câte sunt necesare, iar majoritatea lansărilor au nevoie de unul până la trei. O serie lungă de candidați înseamnă de obicei că înghețarea a fost declarată prea devreme sau că acoperirea cu teste prinde lucrurile târziu.
Poate un release candidate să devină lansarea finală fără modificări? Da, și acesta este rezultatul urmărit. Lansarea finală ar trebui să fie același build ca ultimul candidat, doar redenumit sau re-etichetat ca GA.
Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.