Release candidate (RC): arti dan cara menjalankannya

Release candidate (RC) adalah build yang diyakini tim siap dirilis. Fiturnya lengkap, sudah lolos pengujian yang direncanakan, dan menjadi rilis final tanpa perubahan kecuali ada yang menemukan bug yang cukup serius untuk menghalanginya. Labelnya adalah janji tentang build itu: tidak ada fitur baru, hanya perbaikan untuk blocker. Jika perbaikan diperlukan, tim membuat kandidat baru dan memulai hitungan dari awal.

Apa itu release candidate dalam perangkat lunak?

Ini adalah tahap pra-rilis terakhir sebelum general availability. Idenya, build tersebut adalah kandidat untuk versi final, dan rilis terjadi dengan mempromosikan build yang sama, bukan membuat yang baru. Artikel Wikipedia tentang siklus hidup rilis perangkat lunak menjelaskan urutan yang sama, yaitu alpha, beta, release candidate, dan rilis, dan istilah-istilah ini dipahami luas di proyek open source maupun vendor.

Apa perbedaan beta dan release candidate?

Beta masih boleh berubah. Fitur bisa disesuaikan, antarmuka bisa bergeser, dan tujuannya adalah mempelajari apa yang kurang atau salah. Release candidate sudah berhenti berubah dengan cara itu, dan tujuannya adalah memastikan tidak ada yang menghalangi rilis. Ujian praktisnya adalah apa yang dilakukan tim dengan laporan bug. Di beta, laporan bisa berujung pada perubahan desain. Di RC, laporan hanya berujung pada perbaikan jika bug itu menghalangi rilis, dan sisanya masuk antrean untuk versi berikutnya.

Bagaimana memberi versi pada release candidate?

Pakai sufiks pra-rilis pada versi yang akan Anda rilis. Di bawah Semantic Versioning, tanda hubung diikuti pengenal yang dipisahkan titik menandai pra-rilis, sehingga kandidat pertama untuk 2.4.0 adalah 2.4.0-rc.1, berikutnya 2.4.0-rc.2, dan rilisnya 2.4.0 polos.

Urutan prioritas mengikuti spesifikasi: 2.4.0-rc.1 berada di bawah 2.4.0-rc.2, dan setiap pra-rilis berada di bawah rilisnya. Karena pengenal dibandingkan satu per satu dan angka dibandingkan secara numerik, rc.10 berada di atas rc.9. Nama alpha, beta, dan rc juga terurut secara alfabet dengan benar, dan itu sebagian alasan tim memakainya. Beri tag tiap kandidat di git, seperti dijelaskan di tag git dan rilis, agar commit persisnya tercatat.

Apa kriteria keluar untuk release candidate?

Tuliskan sebelum RC pertama dibuat. Satu set yang bisa dipakai:

• Rangkaian tes otomatis lolos pada commit persis yang di-build.
• Jalur upgrade dari rilis sebelumnya diuji dengan data yang realistis.
• Masalah yang diketahui sudah ditriase, dan tidak ada yang dinilai sebagai blocker.
• Performa dan tingkat error sama dengan rilis sebelumnya dalam batas yang disepakati.
• Release notes sudah disusun dan ditinjau terhadap daftar akhir perubahan.
• Jalur rollback tersedia dan seseorang sudah membacanya.

Jika setiap baris benar untuk sebuah kandidat, kandidat itulah rilisnya. Jika ada satu baris yang gagal, perbaikannya menghasilkan kandidat baru dan pemeriksaan dimulai ulang. Versi tujuh langkah dari alur ini, dengan pemilik untuk tiap langkah, ada di proses manajemen rilis.

Apa yang dilakukan dengan build saat RC lolos?

Promosikan artefak yang sama. Jangan build ulang dari tag, karena build ulang bisa menarik dependensi atau keluaran compiler yang berbeda, dan pengujian yang Anda lakukan berlaku untuk build aslinya. Banyak tim mengganti nama kandidat dengan memberi tag ulang atau mengarahkan ulang label registry, sehingga byte yang diuji adalah byte yang diunduh pengguna.

Untuk paket, terbitkan kandidat di kanal terpisah agar pengguna biasa tidak menerimanya secara tidak sengaja. Dengan npm, npm publish --tag rc membiarkan tag latest bawaan di tempatnya, dan hanya orang yang meminta @rc yang mendapat kandidatnya. Image container dan build mobile punya gagasan yang sama dengan nama lain: tag pra-rilis, rollout bertahap, atau jalur ala TestFlight.

Bagaimana menulis release notes untuk release candidate?

Mulai catatan sejak RC pertama dan jaga agar selaras dengan kandidat-kandidatnya. Penguji perlu tahu apa yang berubah, apa yang perlu diperiksa, dan apa yang diketahui rusak, dan menyusun lebih awal menemukan entri yang tidak diingat siapa pun di akhir. Tandai halaman atau rilis GitHub sebagai pra-rilis agar tidak ada yang mengira itu versi final, dan pindahkan teks yang sudah jadi ke rilis GA saat dirilis. Tata letak dan isinya ada di release notes perangkat lunak, dan sisi GitHub-nya ada di release notes GitHub.

Apakah tim SaaS membutuhkan release candidate?

Tim yang deploy secara kontinu jarang membutuhkannya, karena deploy produksi adalah ujiannya dan feature flag mengendalikan siapa yang melihat perubahan. Release candidate layak dipakai saat pengguna memasang perangkat lunak sendiri dan tidak bisa di-rollback dengan deploy: library, aplikasi desktop dan mobile, produk self-hosted, dan API dengan klien berumur panjang. Untuk produk hosted yang memaparkan perubahan secara bertahap, padanannya adalah rollout bertahap, yang dibahas dari sisi komunikasi oleh artikel release notes feature flag.

FAQ

Apa arti RC dalam perangkat lunak? RC adalah singkatan dari release candidate. Ini adalah build yang ingin dirilis tim sebagai versi final kecuali pengujian menemukan bug yang menghalangi. Ia datang setelah tahap alpha dan beta dan mendahului general availability.

Apakah release candidate cukup stabil untuk produksi? Biasanya ya untuk pengujian di staging atau produksi terbatas, dan ia membawa risiko yang tidak dimiliki rilis final, karena pengujian mungkin belum selesai. Perlakukan sebagai kode berkualitas produksi yang masih dalam masa percobaan.

Berapa banyak release candidate yang sebaiknya dimiliki satu rilis? Sebanyak yang dibutuhkan, dan kebanyakan rilis butuh satu sampai tiga. Rentetan kandidat yang panjang biasanya berarti pembekuan dinyatakan terlalu dini atau cakupan tes menangkap masalah terlambat.

Bisakah release candidate menjadi rilis final tanpa perubahan? Ya, dan itulah hasil yang diharapkan. Rilis final seharusnya build yang sama dengan kandidat terakhir, hanya diganti nama atau labelnya menjadi GA.

Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.

Terkait di changeloop: Dokumentasi developer, Templat catatan rilis