Blue-Green Deployment untuk API: Cara Menguji Sebelum Rilis ke Produksi

Penyebaran blue-green menjanjikan rilis tanpa downtime: Anda menyiapkan salinan baru layanan Anda, mengiriminya beberapa lalu lintas, dan beralih setelah terlihat sehat. Masalahnya adalah kata "sehat." Pemeriksaan kesehatan load balancer biasanya melakukan ping ke satu endpoint dan menunggu kode 200. Itu memberi tahu Anda bahwa prosesnya aktif. Itu tidak memberi tahu Anda apakah build baru Anda mengembalikan JSON yang benar, menghormati kontrak yang sama, atau masih mengautentikasi token seperti yang dilakukan versi lama. Jadi Anda mengaktifkan sakelar, dan pengguna sebenarnya yang pertama menemukan bug yang tidak dapat dilihat oleh pemeriksaan kesehatan Anda.

Panduan ini menjelaskan cara menguji lingkungan hijau seperti yang akan dilakukan pengguna sebelum lalu lintas produksi mencapainya. Anda akan menjalankan serangkaian lengkap tes API terhadap stack yang tidak aktif, menahan pengalihan berdasarkan hasil tersebut, dan menghubungkan semuanya ke pipeline Anda sehingga terjadi pada setiap deployment. Kami akan menggunakan Apidog dan Apidog CLI sebagai lapisan pengujian, karena skenario pengujian yang sama yang Anda buat di aplikasi desktop dapat berjalan tanpa pengawasan di CI terhadap lingkungan mana pun yang Anda tunjuk.

Jika Anda sudah menerapkan blue-green tetapi memperlakukan langkah verifikasi sebagai "klik-klik sebentar," inilah bagian yang mengubahnya menjadi sesuatu yang dapat Anda percayai. Seluruh tujuan menjalankan dua lingkungan yang identik adalah untuk memvalidasi salah satunya dalam kondisi realistis. Pemeriksaan kesehatan adalah batas bawah, bukan batas atas.

TL;DR (Ringkasan)

Penyebaran blue-green menjalankan dua lingkungan produksi yang identik dan mengalihkan router di antara keduanya. Sebelum Anda mengalihkan lalu lintas dari biru (aktif) ke hijau (baru), jalankan seluruh rangkaian pengujian API Anda langsung terhadap hijau. Tahan pengalihan berdasarkan build hijau dari rangkaian tersebut. Dengan Apidog CLI, arahkan skenario pengujian yang sama ke URL dasar hijau di pipeline Anda, gagal dalam deployment jika ada asersi yang rusak, dan baru kemudian alihkan router. Pemeriksaan kesehatan mengonfirmasi proses berjalan; tes API mengonfirmasi kontrak masih berlaku.

Apa sebenarnya penyebaran blue-green itu

Penyebaran blue-green adalah pola rilis yang menjaga dua lingkungan tingkat produksi berdampingan. Satu melayani lalu lintas langsung (sebut saja biru). Yang lain tidak aktif, siap menerima versi berikutnya (hijau). Anda menerapkan build baru ke hijau, memverifikasinya, lalu mengubah satu sakelar (target load balancer, catatan DNS, selektor layanan Kubernetes) sehingga semua lalu lintas sekarang mengalir ke hijau. Biru menjadi siaga yang tidak aktif untuk rilis berikutnya. Jika ada yang rusak, Anda dapat beralih kembali ke biru dalam hitungan detik.

Daya tariknya jelas. Tidak ada jendela pemeliharaan. Pengalihan hampir instan. Dan rollback adalah yang termurah, karena versi sebelumnya masih berjalan dan siap. Bandingkan dengan rolling deployment, di mana Anda mengganti instance di tempat dan build yang buruk sudah melayani sebagian kecil pengguna saat Anda menyadarinya.

Namun pola ini hanya akan membuahkan hasil jika lingkungan hijau benar-benar siap saat Anda beralih. Pemeriksaan kesiapan inilah yang sering diabaikan sebagian besar tim. Mereka mengonfirmasi bahwa lingkungan hijau booting dan lolos ping /health yang dangkal, lalu beralih dan berharap. Bentuk penyebaran blue-green membuat pemeriksaan menyeluruh menjadi mudah. Lingkungan hijau sepenuhnya di-deploy dan dapat dijangkau, hanya saja belum menerima lalu lintas publik, jadi tidak ada alasan untuk melewatkannya. Anda memiliki salinan produksi yang lengkap dan terisolasi yang siap untuk diuji.

Jika Anda ingin mengetahui kosa kata strategi rilis yang lebih luas terlebih dahulu, ulasan kami tentang continuous delivery vs continuous deployment vs continuous integration menetapkan konteks di mana blue-green cocok.

Mengapa pemeriksaan kesehatan bukan pengujian

Inilah celah yang seringkali merugikan tim. Pemeriksaan kesehatan yang khas terlihat seperti ini:

# Load balancer health probe
GET /health -> 200 OK -> mark target healthy

Endpoint tersebut biasanya mengembalikan {"status":"ok"} yang dikodekan secara permanen. Itu tidak menyentuh database Anda. Itu tidak melatih otentikasi. Itu tidak menserialkan sumber daya nyata. Sebuah build dapat melewati probe ini sementara setiap endpoint bisnis mengembalikan kode 500, payload yang salah format, atau skema kemarin.

Pertimbangkan mode kegagalan yang akan dengan senang hati dilewati oleh ping /health:

Migrasi yang tidak berjalan, sehingga GET /orders/{id} gagal karena kolom yang hilang.
Bidang JSON yang diganti namanya (user_id menjadi userId) yang merusak setiap konsumen downstream.
Perubahan otentikasi yang sekarang menolak token yang masih diterbitkan oleh aplikasi seluler.
Peningkatan versi dependensi yang mengubah format tanggal dari ISO 8601 menjadi timestamp Unix.
Header wajib baru yang mengembalikan 400 untuk klien mana pun yang tidak mengirimkannya.

Tak satu pun dari ini menghentikan proses untuk booting. Semuanya merusak pengguna nyata saat Anda mengalihkan lalu lintas. Solusinya bukanlah pemeriksaan kesehatan yang lebih cerdas; ini adalah rangkaian pengujian nyata yang memanggil endpoint Anda seperti yang dilakukan klien, menegaskan kode status, isi respons, skema, dan latensi, lalu melaporkan lulus atau gagal. Ini adalah disiplin yang sama di balik pengujian kontrak API; Anda memeriksa apakah layanan yang berjalan masih sesuai dengan perjanjian yang diandalkan konsumen.

Alur kerja pengujian blue-green, end-to-end

Berikut adalah urutan yang sedang kita bangun. Langkah baru adalah "menguji hijau," dan itu berada di antara deploy dan switch.

Deploy ke hijau. Dorong build baru ke lingkungan yang tidak aktif. Ini muncul dan dapat dijangkau di alamat internal, misalnya https://green.internal.example.com, tetapi belum ada lalu lintas publik yang mencapainya.
Smoke test hijau. Jalankan subset cepat dari permintaan jalur kritis terhadap hijau. Login, ambil sumber daya inti, buat satu. Jika ada yang gagal, berhenti di sini. Biru masih melayani pengguna dan tidak pernah menyadarinya.
Jalankan rangkaian lengkap terhadap hijau. Jalankan skenario pengujian API lengkap Anda (jalur positif, kasus kesalahan, alur otentikasi, asersi skema) yang diarahkan ke URL dasar hijau.
Tahan pengalihan. Jika rangkaian lulus, lanjutkan. Jika ada yang gagal, pipeline berhenti dan lingkungan hijau dirobohkan atau dibiarkan untuk diperiksa. Produksi tidak tersentuh.
Aktifkan sakelar. Arahkan ulang router (load balancer, DNS, atau selektor layanan) dari biru ke hijau.
Verifikasi dalam produksi. Jalankan smoke test yang sama terhadap URL langsung pasca-pengalihan untuk mengonfirmasi bahwa peralihan telah efektif dengan bersih.
Pertahankan biru tetap aktif. Tahan lingkungan lama untuk jendela rollback. Jika pemantauan pasca-pengalihan bermasalah, beralihlah kembali secara instan.

Triknya adalah langkah 2, 3, dan 6 menggunakan definisi pengujian yang sama. Anda membangun skenario sekali dan hanya mengubah URL dasar yang menjadi target runner. Itulah kemampuan yang akan kita siapkan selanjutnya.

Membangun skenario pengujian di Apidog

Sebelum mengotomatiskan apa pun, Anda memerlukan rangkaian pengujian yang layak dijalankan. Apidog memungkinkan Anda membangunnya secara visual, lalu menjalankannya dari baris perintah tanpa menulis ulang apa pun. Unduh Apidog dan buat proyek untuk layanan yang Anda deploy.

Di dalam sebuah proyek, Anda menyusun skenario pengujian dari endpoint API Anda yang sudah ada. Skenario adalah kumpulan permintaan yang berurutan dengan asersi dan penerusan variabel antar langkah. Untuk rangkaian kesiapan blue-green, Anda menginginkan skenario yang mencerminkan apa yang dilakukan klien nyata, bukan hanya ping sekali jalan.

Kumpulan awal yang praktis untuk layanan pesanan:

Alur otentikasi: POST /auth/login dengan kredensial yang valid, asersikan 200, ekstrak token bearer ke dalam variabel, lalu gunakan dalam setiap permintaan berikutnya.
Jalur baca: GET /orders dengan token, asersikan 200, asersikan responsnya adalah array, asersikan setiap item memiliki id, status, dan total.
Sumber daya tunggal: GET /orders/{id}, asersikan skema sesuai dengan definisi OpenAPI Anda, asersikan total adalah angka lebih besar dari nol.
Jalur tulis: POST /orders dengan body yang valid, asersikan 201, asersikan id yang dikembalikan tidak kosong, lalu GET id baru tersebut kembali untuk mengonfirmasi bahwa itu tetap ada.
Kasus negatif: GET /orders/{id} dengan token tidak valid, asersikan 401. POST /orders dengan bidang wajib yang hilang, asersikan 400.

Dua fitur paling penting untuk menangkap kegagalan yang dilewatkan oleh pemeriksaan kesehatan. Pertama, asersi skema: Apidog dapat memvalidasi respons terhadap JSON Schema atau definisi OpenAPI untuk endpoint tersebut, sehingga bidang yang diganti namanya atau diubah tipenya akan menyebabkan pengujian gagal alih-alih lolos ke produksi. Kedua, asersi respons pada nilai spesifik, header, dan waktu respons, sehingga Anda menangkap perubahan halus: perubahan format tanggal, null di mana Anda mengharapkan angka, regresi latensi.

Keputusan desain utama adalah penanganan lingkungan. Jangan mengkodekan secara permanen https://blue.example.com ke dalam permintaan Anda. Definisikan variabel lingkungan untuk URL dasar dan referensikan di mana saja sebagai {{baseUrl}}. Di Apidog Anda menyiapkan lingkungan (Produksi, Hijau, Lokal) dan beralih yang aktif, atau Anda menimpa URL dasar saat runtime dari CLI. Ini adalah disiplin manajemen lingkungan dan rahasia yang sama yang tercakup dalam panduan kami tentang klien API dengan manajemen lingkungan dan rahasia; pengujian Anda tetap identik di seluruh biru dan hijau, hanya target yang bergerak.

Jika Anda ingin menggabungkan skenario-skenario ini menjadi satu unit yang dapat dijalankan, test suites Apidog mengelompokkan beberapa skenario sehingga satu perintah dapat menjalankan seluruh pemeriksaan kesiapan.

Menjalankan rangkaian pengujian dari baris perintah

Aplikasi desktop adalah tempat Anda membangun dan men-debug skenario. CLI adalah yang menjalankan skenario tersebut di pipeline Anda terhadap lingkungan hijau. Instal dengan npm; Anda memerlukan Node.js v16 atau yang lebih baru:

npm install -g apidog-cli

Runner menjalankan skenario pengujian dari konfigurasi CI. Di Apidog, Anda membuat konfigurasi CI untuk skenario pengujian, yang memberi Anda perintah jalankan yang terikat ke token akses. Bentuk dasarnya:

apidog run "https://api.apidog.com/api/v1/api-test/ci-config/<config-id>/detail?token=<token>" \
  -r html,cli \
  --out-file green-readiness

Flag -r memilih reporter. cli mencetak hasil ke terminal sehingga log pipeline Anda menunjukkan dengan tepat asersi mana yang gagal. html menulis laporan mandiri yang dapat Anda arsipkan sebagai artefak build untuk siapa pun yang meninjau deploy. Ada juga reporter JSON jika Anda ingin memasukkan hasil ke alat lain. Flag --out-file memberi nama output sehingga setiap eksekusi dapat dilacak ke sebuah build.

Untuk mengarahkan rangkaian pengujian secara khusus ke lingkungan hijau, runner menerima flag lingkungan sehingga skenario yang sama berjalan terhadap target yang berbeda:

# Test the green (idle) environment before cutover
apidog run "<ci-config-url>" \
  --environment <greenEnvironmentId> \
  -r cli,html \
  --out-file green-pre-switch

Anda juga dapat menjalankan eksekusi sepenuhnya dari file skenario yang diekspor jika Anda lebih suka menyimpan semuanya di repo dan menghindari panggilan jaringan untuk mengambil konfigurasi:

apidog run --exported-data ./tests/orders-readiness.json \
  --variables ./tests/green.variables.json \
  -r cli

Untuk melihat lebih dalam tentang runner dan opsinya dalam konteks pipeline, lihat cara mengotomatiskan pengujian API di CI/CD. Perilaku yang penting untuk blue-green adalah kode keluar: ketika sebuah asersi gagal, CLI akan keluar dengan nilai bukan nol. Fakta tunggal itulah yang memungkinkan Anda mengunci pengalihan. Keluar bukan nol menghentikan pipeline sebelum langkah switch pernah berjalan.

Menghubungkannya ke pipeline GitHub Actions

Berikut adalah langkah verifikasi di dalam alur kerja deployment. Ini mengasumsikan bahwa pekerjaan sebelumnya telah men-deploy build ke lingkungan hijau dan bahwa lingkungan hijau dapat dijangkau dari runner. Pekerjaan tersebut menguji lingkungan hijau, dan hanya eksekusi yang berhasil yang memungkinkan pekerjaan berikutnya melakukan pengalihan.

name: deploy-blue-green

on:
  push:
    branches: [main]

jobs:
  deploy-green:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy build to green environment
        run: ./scripts/deploy-green.sh
      # green is now reachable at https://green.internal.example.com

  test-green:
    needs: deploy-green
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run readiness suite against green
        run: |
          apidog run "${{ secrets.APIDOG_CI_CONFIG_URL }}" \
            --environment "${{ vars.GREEN_ENV_ID }}" \
            -r cli,html \
            --out-file green-readiness
      - name: Archive HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: green-readiness-report
          path: ./green-readiness.html

  switch-traffic:
    needs: test-green        # hanya berjalan jika test-green berhasil
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Flip router from blue to green
        run: ./scripts/switch-to-green.sh
      - name: Smoke test production URL post-switch
        run: |
          npm install -g apidog-cli
          apidog run "${{ secrets.APIDOG_SMOKE_CONFIG_URL }}" \
            --environment "${{ vars.PROD_ENV_ID }}" \
            -r cli

Rantai dependensi melakukan pembatasan untuk Anda. switch-traffic mencantumkan needs: test-green, jadi jika rangkaian kesiapan gagal, pekerjaan switch tidak akan pernah dimulai. Lingkungan hijau tetap tidak aktif, biru terus melayani, dan tidak ada pihak downstream yang terpengaruh. Klausa if: always() pada unggahan artefak berarti Anda mendapatkan laporan HTML bahkan pada kegagalan, yang persis saat Anda ingin membacanya.

Simpan URL konfigurasi CI dan token sebagai rahasia repositori, jangan pernah sebaris. ID lingkungan dapat menjadi variabel repositori karena tidak sensitif. Jika tim Anda berjalan di GitLab, Jenkins, CircleCI, atau Azure Pipelines, strukturnya identik: tahap pengujian yang keluar dengan nilai bukan nol akan memblokir tahap pengalihan. Penjelasan kami tentang mengotomatiskan pengujian API di GitHub Actions mencakup pengaturan runner secara lebih rinci, dan pola yang sama berlaku untuk platform mana pun ini.

Smoke test pertama, rangkaian lengkap kedua

Menjalankan seluruh rangkaian pengujian terhadap lingkungan hijau adalah pembatas yang tepat, tetapi Anda tidak ingin menemukan build yang benar-benar rusak pada menit kedelapan dari eksekusi dua belas menit. Pisahkan verifikasi menjadi dua tahap.

Smoke test adalah skenario kecil yang terdiri dari tiga hingga lima permintaan yang mencakup jalur kritis. Login, baca satu sumber daya, buat satu, baca kembali. Jalankan ini terlebih dahulu. Jika lingkungan hijau tidak dapat melakukan ini, seluruh rangkaian pengujian akan membuang-buang waktu dan Anda harus segera menghentikannya. Jaga agar ini kurang dari tiga puluh detik.

Rangkaian lengkap hanya berjalan setelah smoke test lulus. Di sinilah cakupan luasnya: setiap endpoint, kasus kesalahan, kasus tepi, validasi skema pada setiap respons, permutasi otentikasi, penomoran halaman, header batas laju. Ini lebih lambat dan tidak masalah, karena ini adalah pintu gerbang terakhir sebelum pengguna nyata.

Pendekatan dua tingkat ini adalah logika yang sama di balik pemikiran skenario pengujian vs kasus pengujian: skenario smoke adalah sinyal kepercayaan yang cepat, rangkaian lengkap adalah cakupan yang menyeluruh. Keduanya menunjuk ke URL dasar hijau yang sama; mereka hanya berbeda dalam seberapa banyak yang mereka cakup dan kapan mereka dijalankan.

Catatan tentang data pengujian. Lingkungan hijau adalah lingkungan produksi, jadi berhati-hatilah dengan apa yang dibuat oleh pengujian jalur tulis Anda. Arahkan pengujian tulis ke akun pengujian khusus yang catatannya Anda bersihkan, atau jalankan terhadap instance hijau yang didukung oleh database staging sebelum lapisan data dipromosikan. Memverifikasi perilaku tanpa mencemari data produksi adalah batas yang harus Anda perhatikan, dan penting untuk memahami perbedaan antara sandbox vs lingkungan pengujian saat Anda merancangnya.

Kesalahan umum yang menggagalkan seluruh tujuan

Tim mengadopsi blue-green namun masih mengalami kegagalan. Biasanya karena salah satu hal berikut.

Menguji biru alih-alih hijau. Jika rangkaian pengujian Anda mengarah ke URL langsung, Anda menguji versi yang sudah ada di produksi, bukan yang akan Anda rilis. Selalu targetkan URL dasar hijau secara eksplisit sebelum pengalihan.
Hanya memeriksa kode status. Kode 200 dengan body yang salah masih merupakan respons yang rusak. Tegaskan bentuk payload dan nilai kunci, bukan hanya status HTTP. Asersi skema adalah yang menangkap penggantian nama field dan perubahan tipe.
Melewatkan kasus negatif. Build yang mengembalikan 200 untuk token tidak valid adalah regresi keamanan yang tidak akan pernah tertangkap oleh pengujian happy-path. Sertakan kasus 401, 403, dan 400 dalam gerbang.
Tidak ada disiplin rollback. Kekuatan super blue-green adalah rollback instan, tetapi hanya jika Anda menjaga biru tetap hangat. Jangan merobohkannya begitu hijau aktif. Tahan selama jendela pemantauan Anda.
URL yang dikodekan secara permanen dalam permintaan pengujian. Saat URL dasar dibenamkan dalam permintaan, Anda kehilangan kemampuan untuk menjalankan rangkaian yang sama terhadap hijau dan biru. Gunakan variabel lingkungan untuk host, setiap saat.
Memperlakukan pemeriksaan kesehatan sebagai gerbang. Seluruh artikel, dalam satu baris. Probe memberi tahu load balancer bahwa sebuah proses ada. Pengujian API Anda memberi tahu Anda bahwa kontrak tetap berlaku.

Blue-green versus canary: di mana pengujian cocok

Blue-green bukanlah satu-satunya strategi tanpa downtime, dan pendekatan pengujian bergeser dengan masing-masing.

Strategi	Bagaimana lalu lintas bergerak	Di mana pengujian API cocok
Blue-green	Sekaligus, biru ke hijau	Rangkaian lengkap terhadap hijau sebelum pengalihan; gerbang adalah pra-pengalihan
Canary	Secara bertahap, persentase kecil ke versi baru	Asersi berkelanjutan pada bagian canary; promosi berdasarkan metrik yang bersih
Rolling	Instance per instance, di tempat	Pemeriksaan smoke per instance; lebih sulit untuk digerbang karena peluncuran sudah berjalan
Recreate	Hentikan yang lama, mulai yang baru (dengan downtime)	Rangkaian berjalan selama jendela; downtime adalah imbal balik

Blue-green memberikan Anda gerbang terbersih dari keempatnya karena lingkungan hijau sepenuhnya di-deploy dan sepenuhnya terisolasi saat Anda mengujinya. Anda mendapatkan replika produksi lengkap untuk diverifikasi, dengan nol paparan pengguna, dan satu sakelar atomik. Canary menukar gerbang yang bersih itu dengan paparan bertahap dan lebih mengandalkan pemantauan langsung. Untuk sebagian besar layanan yang didukung API, blue-green ditambah rangkaian pra-pengalihan adalah cara termudah untuk mendapatkan kepercayaan tinggi tanpa jendela pemeliharaan.

Bentuk dunia nyata dari ini

Sebuah tim fintech yang menjalankan API pembayaran menggunakan blue-green untuk setiap rilis karena deployment yang buruk bukanlah bug kosmetik, melainkan transaksi yang gagal. Gerbang mereka adalah rangkaian empat puluh skenario terhadap lingkungan hijau yang mencakup otentikasi, kunci idempoten, pembulatan mata uang, dan tanda tangan webhook. Jalur penuh membutuhkan waktu sekitar enam menit. Tidak ada yang mencapai produksi sampai semuanya hijau, dan laporan HTML dilampirkan pada setiap deployment untuk jejak audit.

Tim SaaS dengan API publik menjalankan versi yang lebih ramping: gerbang smoke dua belas skenario terhadap lingkungan hijau, lalu pengalihan, lalu smoke test pasca-pengalihan terhadap URL langsung. Prioritas mereka adalah menangkap schema drift, karena integrasi pihak ketiga akan rusak parah ketika sebuah field berubah bentuk. Asersi skema pada setiap respons adalah inti dari gerbang mereka.

Kedua tim membangun skenario sekali di Apidog dan menjalankannya secara otomatis dari CLI pada setiap push. Aplikasi desktop tetap menjadi tempat di mana para insinyur men-debug dan memperluas skenario; pipeline adalah tempat skenario yang sama itu menjadi gerbang rilis.

Kesimpulan

Penyebaran blue-green memberi Anda salinan produksi yang gratis, sepenuhnya di-deploy, dan tidak aktif sebelum setiap rilis. Menyia-nyiakannya dengan hanya memeriksa probe kesehatan yang dangkal adalah cara paling umum tim mengirimkan kerusakan dengan strategi tanpa downtime. Solusinya adalah menguji lingkungan hijau seperti pengguna sebelum Anda mengaktifkan sakelar.

Bagian-bagiannya:

Bangun skenario pengujian nyata (otentikasi, baca, tulis, kasus negatif, asersi skema) sekali, di Apidog.
Gunakan variabel lingkungan untuk URL dasar sehingga rangkaian yang sama berjalan terhadap lingkungan hijau dan biru tanpa perubahan.
Jalankan smoke test cepat terlebih dahulu, lalu rangkaian lengkap, keduanya diarahkan ke lingkungan hijau.
Tahan pengalihan pada kode keluar rangkaian di pipeline Anda sehingga kegagalan memblokir pengalihan.
Pertahankan biru tetap aktif untuk rollback instan melalui jendela pemantauan Anda.

Atur ini sekali dan setiap deployment akan secara otomatis mendapatkan gerbang yang sama. Unduh Apidog untuk membangun rangkaian kesiapan Anda, buat konfigurasi CI, dan masukkan langkah apidog run ke pipeline Anda sebelum tahap pengalihan. Pengguna nyata pertama Anda seharusnya tidak pernah menjadi pengujian nyata pertama Anda.

button

FAQ

Apa itu penyebaran blue-green dalam istilah sederhana? Ini adalah menjalankan dua lingkungan produksi yang identik dan mengalihkan semua lalu lintas di antara keduanya. Satu (biru) melayani pengguna langsung sementara yang lain (hijau) mendapatkan versi baru. Anda menguji hijau, lalu mengaktifkan satu sakelar sehingga hijau menjadi aktif. Biru tetap sebagai target rollback instan.

Bagaimana cara menguji lingkungan hijau sebelum mengalihkan lalu lintas? Arahkan rangkaian pengujian API Anda ke URL dasar lingkungan hijau dan jalankan di pipeline Anda sebelum langkah pengalihan. Dengan Apidog CLI, jalankan skenario Anda dengan apidog run terhadap lingkungan hijau, gagal dalam deployment jika ada asersi yang rusak, dan hanya alihkan lalu lintas jika rangkaian lulus.

Mengapa pemeriksaan kesehatan load balancer tidak cukup untuk blue-green? Pemeriksaan kesehatan biasanya melakukan ping ke satu endpoint dan mengonfirmasi 200, yang hanya membuktikan bahwa proses sedang berjalan. Ini tidak akan menangkap bidang JSON yang diganti namanya, migrasi yang gagal, alur otentikasi yang rusak, atau perubahan skema. Rangkaian pengujian API nyata menegaskan pada body respons, skema, dan kasus kesalahan, sehingga menangkap kegagalan yang dilewati oleh probe kesehatan.

Dapatkah saya menjalankan pengujian API yang sama di CI yang saya buat di aplikasi desktop? Ya. Skenario yang Anda bangun secara visual di Apidog berjalan tanpa perubahan dari Apidog CLI. Anda membuat konfigurasi CI untuk sebuah skenario, lalu memanggil apidog run dengan konfigurasi tersebut di GitHub Actions, GitLab CI, Jenkins, atau pipeline apa pun. CLI keluar dengan nilai bukan nol pada kegagalan, yang memungkinkan Anda mengunci deployment.

Apa perbedaan antara penyebaran blue-green dan canary untuk pengujian? Blue-green mengalihkan semua lalu lintas sekaligus setelah Anda menguji lingkungan hijau yang sepenuhnya di-deploy, sehingga gerbangnya adalah pra-pengalihan. Canary mengalihkan lalu lintas secara bertahap ke bagian kecil dan mengandalkan pemantauan langsung dari bagian tersebut. Blue-green memberikan gerbang pengujian pra-rilis yang lebih bersih; canary memberikan paparan dunia nyata secara bertahap.

Haruskah saya menjalankan pengujian jalur tulis terhadap lingkungan produksi hijau? Berhati-hatilah dengan data. Gunakan akun pengujian khusus yang catatannya Anda bersihkan, atau jalankan pengujian tulis terhadap instance hijau yang didukung oleh database staging sebelum mempromosikan lapisan data. Tujuannya adalah memverifikasi perilaku tanpa mencemari data produksi, yang merupakan batas antara sandbox dan pengujian produksi sejati.

Seberapa cepat gerbang pengujian pra-pengalihan harus berjalan? Pisahkan. Jalankan smoke test tiga hingga lima permintaan jalur kritis dalam waktu kurang dari tiga puluh detik untuk gagal dengan cepat, lalu jalankan rangkaian lengkap (setiap endpoint, kasus kesalahan, pemeriksaan skema) hanya jika smoke test lulus. Gerbang lengkap dari beberapa lusin skenario biasanya selesai dalam beberapa menit, yang dapat diterima untuk gerbang rilis.