Release candidate (RC): ne demek ve nasıl yönetilir
4 dk okuma
Release candidate (RC), ekibin yayına hazır olduğuna inandığı build’dir. Özellik açısından tamamlanmıştır, planlanan testlerden geçmiştir ve biri onu engelleyecek kadar ciddi bir hata bulmadıkça değişmeden nihai sürüm olur. Etiket build hakkında bir sözdür: yeni özellik yok, yalnızca engelleyici hataların düzeltmeleri. Bir düzeltme gerekirse ekip yeni bir aday çıkarır ve süreyi baştan başlatır.
| Aşama | Özellikler | Hedef kitle | Beklenen durum |
|---|---|---|---|
| Alfa | Hâlâ ekleniyor | İç ekip | Eksik, çok sayıda bilinen hata |
| Beta | Tamam ya da neredeyse tamam | Gönüllüler ve seçilmiş müşteriler | Kullanılabilir, hata beklenir |
| Release candidate | Dondurulmuş | Test edenler ve erken benimseyenler | Hazır olduğuna inanılır, yalnızca engelleyiciler düzeltilir |
| Genel kullanıma sunum (GA) | Dondurulmuş | Herkes | Son RC ile aynı build |
Yazılımda release candidate nedir?
Genel kullanıma sunumdan önceki son ön sürüm aşamasıdır. Fikir, build’in nihai sürüm için bir aday olmasıdır; release, yeni bir build üretilerek değil, aynı build terfi ettirilerek yapılır. Vikipedi’deki yazılım sürüm yaşam döngüsü makalesi alfa, beta, release candidate ve release dizisini aynı biçimde anlatır; bu terimler açık kaynak projelerde ve yazılım üreticilerinde yaygın olarak anlaşılır.
Beta ile release candidate arasındaki fark nedir?
Beta’nın hâlâ değişmesine izin vardır. Özellikler ayarlanabilir, arayüzler kayabilir ve amaç neyin eksik ya da yanlış olduğunu öğrenmektir. Release candidate ise bu biçimlerde değişmeyi bırakmıştır ve amaç hiçbir şeyin release’i engellemediğini doğrulamaktır. Pratik test, ekibin bir hata raporuyla ne yaptığıdır. Beta’da bir rapor tasarım değişikliğine yol açabilir. RC’de ise bir rapor, ancak hata yayını engelliyorsa düzeltmeye yol açar; geri kalan her şey bir sonraki sürüme sıraya alınır.
Release candidate’e nasıl sürüm numarası verilir?
Yayına çıkaracağınız sürümün üzerine bir ön sürüm eki ekleyin. Semantic Versioning kapsamında tire ve ardından noktayla ayrılmış tanımlayıcılar bir ön sürümü belirtir; bu yüzden 2.4.0 için ilk aday 2.4.0-rc.1, sonraki 2.4.0-rc.2 ve release düz 2.4.0’dır.
Öncelik sırası spesifikasyonu izler: 2.4.0-rc.1, 2.4.0-rc.2’nin altında sıralanır ve her ön sürüm release’in altında sıralanır. Tanımlayıcılar tek tek karşılaştırıldığı ve sayılar sayısal olarak kıyaslandığı için rc.10, rc.9’un üstünde sıralanır. Alfa, beta ve rc adları da alfabetik olarak doğru sırada dizilir; ekiplerin bunları kullanmasının nedenlerinden biri budur. Tam commit’in kaydedilmesi için her adayı git etiketleri ve release’ler yazısında anlatıldığı gibi git’te etiketleyin.
Release candidate için çıkış kriterleri nelerdir?
Bunları ilk RC çıkarılmadan önce yazın. İşe yarar bir küme:
- Otomatik test paketi, build edilen tam commit üzerinde geçer.
- Önceki release’ten yükseltme yolu gerçekçi verilerle test edilmiştir.
- Bilinen sorunlar sınıflandırılmıştır ve hiçbiri engelleyici olarak derecelendirilmemiştir.
- Performans ve hata oranları, üzerinde anlaşılan bir payla önceki release ile eşleşir.
- Release notes taslağı hazırlanmış ve nihai değişiklik listesine göre gözden geçirilmiştir.
- Bir geri alma yolu vardır ve biri onu okumuştur.
Bir aday için her satır doğruysa o aday release’tir. Herhangi bir satır başarısız olursa düzeltme yeni bir aday üretir ve kontroller yeniden başlar. Bu akışın her adım için sahipleriyle birlikte yedi adımlı hali release yönetimi süreci yazısında.
Bir RC geçtiğinde build ile ne yapmalısınız?
Aynı artifact’i terfi ettirin. Etiketten yeniden build etmeyin; çünkü yeniden build farklı bir bağımlılık ya da derleyici çıktısı getirebilir ve yaptığınız test orijinal build için geçerliydi. Birçok ekip adayı yeniden etiketleyerek ya da bir registry etiketini başka yere göstererek yeniden adlandırır; böylece test edilen baytlar, kullanıcıların indirdiği baytlardır.
Paketlerde adayları ayrı bir kanalda yayımlayın ki sıradan kullanıcılar bunları yanlışlıkla almasın. npm ile npm publish --tag rc, varsayılan latest etiketini olduğu yerde bırakır ve adayı yalnızca @rc isteyenler alır. Container imajları ve mobil build’lerde aynı fikir başka adlarla geçer: bir ön sürüm etiketi, kademeli bir yayın ya da TestFlight benzeri bir kanal.
Release candidate için release notes nasıl yazılır?
Notlara ilk RC ile başlayın ve adaylarla uyumlu tutun. Test edenlerin neyin değiştiğini, neyi kontrol edeceklerini ve neyin bozuk olduğunun bilindiğini öğrenmesi gerekir; erken taslak hazırlamak da sonunda kimsenin hatırlamadığı kayıtları ortaya çıkarır. Sayfayı ya da GitHub release’ini ön sürüm olarak işaretleyin ki kimse onu nihai sürümle karıştırmasın, bittiğinde ise son metni GA release’ine taşıyın. Düzen ve içerik yazılım release notes yazısında, GitHub tarafı ise GitHub release notes yazısında.
SaaS ekiplerinin release candidate’e ihtiyacı var mı?
Sürekli deploy eden ekiplerde nadiren, çünkü production deploy’u testtir ve bir değişikliği kimin göreceğini bir feature flag belirler. Release candidate’ler, kullanıcılar yazılımı kendileri kurduğunda ve bir deploy ile geri alınamadığında yerini hak eder: kütüphaneler, masaüstü ve mobil uygulamalar, kendi sunucusunda barındırılan ürünler ve uzun ömürlü istemcileri olan API’ler. Değişiklikleri kademeli olarak gösteren barındırılan bir ürün için karşılığı kademeli yayındır; bunu iletişim açısından feature flag release notları yazısı ele alır.
FAQ
Yazılımda RC ne demek? RC, release candidate’in kısaltmasıdır. Test engelleyici bir hata bulmadıkça ekibin nihai sürüm olarak yayımlamayı planladığı build’dir. Alfa ve beta aşamalarından sonra gelir ve genel kullanıma sunumdan öncedir.
Release candidate production için yeterince kararlı mıdır? Çoğunlukla staging ya da sınırlı bir production ortamında test için evet; nihai release’in taşımadığı bir risk taşır, çünkü test bitmemiş olabilir. Onu hâlâ deneme sürecindeki, production kalitesinde kod olarak görün.
Bir release kaç release candidate içermeli? Gerektiği kadar; çoğu release için bir ila üç aday yeterlidir. Uzun bir aday dizisi genellikle dondurmanın çok erken ilan edildiği ya da test kapsamının sorunları geç yakaladığı anlamına gelir.
Release candidate değişmeden nihai release olabilir mi? Evet, amaçlanan sonuç da budur. Nihai release, son adayla aynı build olmalı; yalnızca yeniden adlandırılmış ya da GA olarak yeniden etiketlenmiş olmalıdır.
Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.