Merilis perangkat lunak biasanya berarti jendela pemeliharaan dan semoga saja. Tim modern menggunakan strategi yang membuat rilis menjadi rutin, dan pilihan penerapan biru-hijau vs kenari adalah salah satu pilihan pertama yang akan Anda hadapi. Keduanya mengurangi risiko, namun melakukannya dengan cara yang berlawanan: yang satu menyiapkan pengganti penuh, sementara yang lain menguji dengan pengguna sebenarnya sedikit demi sedikit.

Panduan ini menjelaskan cara kerja masing-masing dan berapa biaya praktiknya. Kami menjalankan contoh kecil perutean pengguna dan rollback di Python 3.13, dan hasilnya berasal dari proses tersebut. Sampel Kubernetes hanya bersifat ilustratif, dan kami tidak menjalankannya. Perlakukan persentase dan ambang batas sebagai contoh awal untuk beradaptasi.

Jawaban singkatnya

Dengan penerapan biru-hijau, Anda menjalankan dua lingkungan produksi yang identik. Yang satu melayani pengguna saat Anda menerapkan dan menguji versi baru di versi lainnya, lalu Anda mengalihkan semua lalu lintas dalam satu gerakan.

Dengan penerapan canary, versi baru berjalan di samping versi lama. Anda mengirimkannya sebagian kecil dari lalu lintas nyata, membandingkan hasilnya, dan meningkatkan pembagiannya selangkah demi selangkah hingga dapat melayani semua orang. Nama burung kenari ini berasal dari nama burung kenari penambang yang pernah digunakan sebagai peringatan dini akan adanya bahaya.

Biru-hijau vs kenari berdampingan

Cara kerja penerapan biru-hijau

1. Biru aktif dan melayani semua lalu lintas.
2. Terapkan versi baru ke hijau, yang tidak menerima lalu lintas pengguna.
3. Uji hijau secara menyeluruh, di lingkungan produksi nyata, menggunakan uji asap dan pengguna internal.
4. Ganti router, penyeimbang beban, atau DNS untuk mengirim lalu lintas ke warna hijau.
5. Perhatikan baik-baik, dengan warna biru masih berjalan dan siap.
6. Jika ada yang salah, beralih kembali. Jika semuanya baik-baik saja, warna biru menjadi lingkungan menganggur berikutnya.

Di Kubernetes, Anda dapat melakukan peralihan dengan mengubah pemilih Layanan, sehingga lalu lintas berpindah ke Pod yang diberi label berbeda:

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

Kelebihan: Konsepnya sederhana, Anda dapat menguji penyiapan produksi yang tepat sebelum pengguna melihatnya, dan rollback hampir seketika. Kelemahan: Infrastruktur duplikat bisa memakan biaya yang mahal, bug yang lolos dari pengujian Anda dapat menjangkau semua orang sekaligus, dan sesi terbuka serta pekerjaan dalam penerbangan memerlukan perhatian selama peralihan. Jika Anda menggunakan DNS untuk peralihan, catatan cache dapat menundanya. Baru mengenal konsepnya? Lihat Tutorial Kubernetes untuk pemula kami.

Cara kerja penerapan canary

1. Terapkan versi baru bersama versi stabil.
2. Rutekan sebagian kecil lalu lintas, misalnya 5%, ke canary.
3. Bandingkan tingkat kesalahan, latensi, dan metrik bisnis dengan versi stabil.
4. Kalau sehat naikkan jadi 25%, lalu 50%, lalu 100%.
5. Jika ada yang menurun, kembalikan semua lalu lintas ke versi stabil.

Banyak tim memulai proyek dengan staf internal, kemudian wilayah berisiko rendah, dan baru kemudian masyarakat luas.

Kelebihan: Rilis yang buruk hanya memengaruhi sekelompok kecil, dan Anda belajar dari lalu lintas nyata bahwa tidak ada lingkungan pengujian yang dapat direproduksi sepenuhnya. Kelemahan: Anda memerlukan perutean berbasis persentase dan metrik per versi, peluncuran membutuhkan waktu lebih lama, dan dua versi dijalankan bersamaan untuk sementara waktu. Burung kenari kecil juga bisa menjadi terlalu sunyi untuk memberikan sinyal yang berarti, terutama pada saat lalu lintas sepi.

Perutean pengguna yang stabil

Memilih versi secara acak pada setiap permintaan memberikan pengalaman yang membingungkan bagi pengguna, karena mereka mungkin beralih antara versi lama dan baru. Solusi umum adalah dengan meng-hash ID pengguna yang stabil ke dalam keranjang, sehingga setiap pengguna selalu mendapatkan jawaban yang sama:

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

Proporsi sebenarnya sudah sesuai dengan target. Metode ini memiliki dua properti yang lebih berguna, dan proses kami mengonfirmasi keduanya. Pengguna yang sama selalu menerima versi yang sama. Dan semua orang di kelompok 5% masih termasuk dalam 25%, jadi tidak ada orang yang sudah memiliki versi baru yang dipindahkan kembali seiring dengan berkembangnya peluncuran.

Dalam sistem nyata, mesh layanan, penyeimbang beban, atau alat seperti Argo Rollouts atau Flagger biasanya menangani perutean ini, jadi Anda tidak perlu menulisnya sendiri. Memahami apa yang mereka lakukan masih bermanfaat.

Mengotomatiskan keputusan

Canary hanya berfungsi jika seseorang benar-benar membandingkan versinya. Pemeriksaan otomatis lebih dapat diandalkan dibandingkan seseorang yang mengamati grafik. Inilah ide intinya, membandingkan tingkat kesalahan canary dengan versi stabil:

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

Perhatikan kasus pertama. Tingkat kesalahannya terlihat tinggi, namun dengan hanya 100 permintaan, itu belum cukup bukti. Alat nyata menerapkan statistik yang lebih cermat, dan alat tersebut melihat beberapa sinyal secara bersamaan:

Masalah basis data

Kode aplikasi dapat ditukar dalam hitungan detik, namun data tidak. Kedua strategi tersebut biasanya berbagi satu database, jadi selama peluncuran dan setelah rollback, versi lama dan baru harus bekerja dengan skema yang sama.

Jawaban standarnya adalah pola perluas dan kontrak. Misalkan Anda ingin mengganti nama name menjadi full_name:

1. Perluas: tambahkan kolom baru. Kode lama tidak terpengaruh.
2. Migrasi: kode rilis yang menulis ke kedua kolom, dan mengisi ulang baris lama.
3. Beralih: kode rilis yang dibaca dari kolom baru.
4. Kontrak: setelah tidak ada yang menggunakan kolom lama, hapus kolom tersebut di rilis selanjutnya.

Ini memerlukan beberapa rilis, namun setiap langkah dapat dibatalkan dengan aman. Menjalankan RENAME COLUMN sekaligus akan merusak versi mana pun yang diharapkan dari nama lainnya. Berhati-hatilah dengan perubahan skema yang berjalan lama, karena perubahan tersebut dapat mengunci. Untuk mengetahui lebih lanjut mengenai hal ini, baca tentang transaksi SQL.

Bergulir dan strategi lainnya

Deployment Kubernetes melakukan pembaruan berkelanjutan secara default, yang cocok untuk banyak layanan. Pembaruan berkelanjutan juga bergeser secara bertahap, namun bagiannya terkait dengan jumlah contoh, dan tidak dengan sendirinya menganalisis hasil atau berhenti pada metrik yang buruk.

Bagaimana dengan tanda fitur?

Deployment menempatkan kode di server, dan rilis membuat fitur tersedia bagi pengguna. Tanda fitur memisahkannya, dengan memungkinkan Anda mengaktifkan fitur untuk pengguna yang dipilih tanpa menerapkan apa pun. Mereka bekerja sangat baik dengan kedua strategi tersebut: terapkan tanpa tanda, lalu aktifkan secara bertahap. Mereka tidak menggantikan strategi ini, karena sebuah flag tidak dapat melindungi Anda dari rilis yang crash saat startup. Ingatlah untuk menghapus tanda-tanda lama, karena hal itu akan menumpuk sebagai utang teknis.

Bagaimana memilih

Mereka juga bisa digabungkan. Beberapa tim menerapkan lingkungan hijau, dan kemudian mengalihkan lalu lintas ke sana secara bertahap, mendapatkan lingkungan yang bersih dan radius ledakan terbatas. Apa pun yang Anda pilih, otomatiskan melalui pipa CI/CD Anda, seperti yang dijelaskan dalam panduan Tindakan GitHub kami.

Kesalahan umum

• Membuat perubahan skema yang dapat menyebabkan gangguan. Rollback tidak membantu jika kode lama tidak dapat membaca data.
• Tidak memiliki kriteria rollback. Putuskan apa yang dimaksud dengan “buruk” sebelum rilis dimulai, bukan saat terjadi insiden.
• Membiarkan lingkungan melayang. Jika warna hijau berbeda dengan biru, pengujian Anda kurang membuktikannya. Definisikan keduanya dengan infrastruktur sebagai kode.
• Hanya mengukur metrik teknis. Rilis bisa bebas kesalahan dan tetap membatalkan proses pembayaran.
• Jangan pernah berlatih rollback. Latihlah, agar berhasil saat Anda berada di bawah tekanan.
• Melupakan pekerjaan latar belakang. Pekerja dan tugas terjadwal juga memerlukan rencana selama peralihan.

Penutup

Biru-hijau memberi Anda peralihan yang bersih dan cepat. Canary memberi Anda eksposur kecil dan terukur. Jika pemantauan Anda masih dasar, mulailah dengan pembaruan berkelanjutan atau biru-hijau, dan berinvestasilah pada metrik per versi sebelum Anda mencoba canaries. Kemudian latih rollback pada rilis berikutnya, termasuk database. Latihan tunggal tersebut cenderung mengungkapkan apa yang sebenarnya perlu diperbaiki.

Pertanyaan yang sering diajukan

Teruslah belajar