Release candidate (RC): co oznacza i jak go poprowadzić

Release candidate (RC) to build, który zespół uważa za gotowy do wydania. Ma komplet funkcji, przeszedł zaplanowane testy i staje się wydaniem finalnym bez zmian, chyba że ktoś znajdzie błąd na tyle poważny, by go zablokować. Etykieta jest obietnicą co do builda: żadnych nowych funkcji, tylko poprawki blokerów. Jeśli poprawka jest potrzebna, zespół przygotowuje nowego kandydata i odmierzanie czasu zaczyna się od nowa.

Czym jest release candidate w oprogramowaniu?

To ostatni etap przed ogólną dostępnością. Idea jest taka, że build jest kandydatem na wersję finalną, a wydanie polega na awansowaniu tego samego builda, a nie na tworzeniu nowego. Artykuł Wikipedii o cyklu życia wydań oprogramowania opisuje tę samą sekwencję: alfa, beta, release candidate i wydanie, a te terminy są powszechnie rozumiane w projektach open source i u dostawców.

Czym różni się beta od release candidate?

Beta wciąż może się zmieniać. Funkcje można korygować, interfejsy przesuwać, a celem jest dowiedzenie się, czego brakuje lub co jest złe. Release candidate przestał się zmieniać w ten sposób, a jego celem jest potwierdzenie, że nic nie blokuje wydania. Praktyczny test to to, co zespół robi ze zgłoszeniem błędu. W becie zgłoszenie może prowadzić do zmiany projektu. W RC zgłoszenie prowadzi do poprawki tylko wtedy, gdy błąd blokuje wydanie, a wszystko inne trafia do kolejki na następną wersję.

Jak wersjonować release candidate?

Użyj sufiksu wersji wstępnej przy wersji, którą zamierzasz wydać. Według Semantic Versioning myślnik, po którym następują identyfikatory rozdzielone kropkami, oznacza wersję wstępną, więc pierwszy kandydat na 2.4.0 to 2.4.0-rc.1, następny to 2.4.0-rc.2, a wydanie to zwykłe 2.4.0.

Pierwszeństwo wynika ze specyfikacji: 2.4.0-rc.1 jest niższe niż 2.4.0-rc.2, a każda wersja wstępna jest niższa niż wydanie. Ponieważ identyfikatory porównuje się jeden po drugim, a liczby numerycznie, rc.10 jest wyżej niż rc.9. Nazwy alpha, beta i rc sortują się też alfabetycznie w dobrej kolejności, co jest jednym z powodów, dla których zespoły z nich korzystają. Otaguj każdego kandydata w git, jak opisano w tekście tagi git i wydania, żeby dokładny commit był zapisany.

Jakie są kryteria wyjścia dla release candidate?

Spisz je, zanim powstanie pierwszy RC. Sprawdzający się zestaw:

• Zautomatyzowany zestaw testów przechodzi na dokładnie tym commicie, z którego zbudowano build.
• Ścieżka aktualizacji z poprzedniego wydania została przetestowana na realistycznych danych.
• Znane problemy są przejrzane i żaden nie jest oceniony jako bloker.
• Wydajność i poziom błędów zgadzają się z poprzednim wydaniem w uzgodnionym marginesie.
• Release notes są napisane i sprawdzone z końcową listą zmian.
• Istnieje ścieżka wycofania i ktoś ją przeczytał.

Gdy każda linijka jest prawdziwa dla danego kandydata, ten kandydat jest wydaniem. Jeśli którakolwiek zawodzi, poprawka daje nowego kandydata i kontrole zaczynają się od nowa. Siedmiostopniową wersję tego przepływu, z właścicielami każdego kroku, opisuje proces zarządzania wydaniami.

Co zrobić z buildem, gdy RC przejdzie?

Awansuj ten sam artefakt. Nie buduj ponownie z tagu, bo ponowny build może pobrać inną zależność lub dać inny wynik kompilatora, a testy, które wykonałeś, dotyczyły oryginalnego builda. Wiele zespołów zmienia nazwę kandydata przez ponowne otagowanie lub przestawienie etykiety w rejestrze, żeby bajty, które testowano, były bajtami, które użytkownicy pobierają.

Dla pakietów publikuj kandydatów w osobnym kanale, żeby zwykli użytkownicy nie dostawali ich przypadkiem. W npm npm publish --tag rc zostawia domyślny tag latest tam, gdzie był, a kandydata dostają tylko ci, którzy poproszą o @rc. Obrazy kontenerów i buildy mobilne mają ten sam pomysł pod innymi nazwami: tag wersji wstępnej, stopniowe wdrażanie lub ścieżka w stylu TestFlight.

Jak napisać release notes dla release candidate?

Zacznij notatki od pierwszego RC i prowadź je równolegle z kandydatami. Testerzy muszą wiedzieć, co się zmieniło, co sprawdzić i co jest znanym błędem, a pisanie od wczesnego etapu wyłapuje wpisy, których pod koniec nikt nie pamięta. Oznacz stronę lub wydanie na GitHubie jako wersję wstępną, żeby nikt nie wziął jej za finalną, a gotowy tekst przenieś do wydania GA, gdy wyjdzie. Układ i zawartość opisuje release notes oprogramowania, a stronę GitHuba GitHub release notes.

Czy zespoły SaaS potrzebują release candidate?

Zespoły wdrażające w sposób ciągły rzadko ich potrzebują, bo wdrożenie na produkcję jest testem, a flaga funkcji kontroluje, kto widzi zmianę. Release candidate zasługują na miejsce, gdy użytkownicy instalują oprogramowanie sami i nie da się go cofnąć wdrożeniem: biblioteki, aplikacje desktopowe i mobilne, produkty self-hosted i API z długo żyjącymi klientami. Dla produktu hostowanego, który ujawnia zmiany stopniowo, odpowiednikiem jest stopniowe wdrażanie, które od strony komunikacji omawia tekst o release notes przy flagach funkcji.

FAQ

Co znaczy RC w oprogramowaniu? RC to skrót od release candidate. To build, który zespół zamierza wydać jako wersję finalną, chyba że testy znajdą błąd blokujący. Następuje po etapach alfa i beta, a poprzedza ogólną dostępność.

Czy release candidate jest wystarczająco stabilny na produkcję? Zwykle tak do testów w środowisku stagingowym lub w ograniczonej produkcji, ale niesie ryzyko, którego nie ma wydanie finalne, bo testy mogą nie być skończone. Traktuj go jak kod jakości produkcyjnej, który wciąż jest na okresie próbnym.

Ile release candidate powinno mieć jedno wydanie? Tyle, ile trzeba, a większość wydań potrzebuje od jednego do trzech. Długa seria kandydatów zwykle znaczy, że zamrożenie ogłoszono za wcześnie albo pokrycie testami wyłapuje błędy za późno.

Czy release candidate może zostać wydaniem finalnym bez zmian? Tak, i taki jest zamierzony wynik. Wydanie finalne powinno być tym samym buildem co ostatni kandydat, tylko przemianowanym lub oznaczonym jako GA.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Dokumentacja dla deweloperów, Szablon notatek wydania