Blue-green dağıtım sıfır kesinti süreli yayınlar vaat eder: hizmetinizin yeni bir kopyasını kurarsınız, ona biraz trafik gönderirsiniz ve sağlıklı göründüğünde geçiş yaparsınız. Sorun, “sağlıklı” kelimesindedir. Bir yük dengeleyici sağlık kontrolü genellikle tek bir uç noktaya ping atar ve bir `200` yanıtı bekler. Bu size sürecin çalıştığını söyler. Yeni yapınızın doğru JSON'ı döndürüp döndürmediği, aynı sözleşmeyi yerine getirip getirmediği veya eski sürümün yaptığı gibi bir belirteci hala doğrulayıp doğrulamadığı hakkında hiçbir şey söylemez. Böylece anahtarı çevirirsiniz ve ilk gerçek kullanıcı, sağlık kontrolünüzün göremediği hatayı bulur.
Bu kılavuz, yeşil ortamı, herhangi bir üretim trafiği ona ulaşmadan önce bir kullanıcının test edeceği şekilde nasıl test edeceğinizi anlatıyor. Boşta duran yığına karşı eksiksiz bir API test paketi çalıştıracak, geçişi bu sonuçlara bağlayacak ve tüm sistemi pipeline'ınıza bağlayarak her dağıtımda gerçekleşmesini sağlayacaksınız. Test katmanı olarak Apidog ve Apidog CLI'yi kullanacağız, çünkü masaüstü uygulamasında oluşturduğunuz aynı test senaryoları, hangi ortama yönlendirirseniz yönlendirin, CI'da gözetimsiz çalışabilir.
Eğer zaten blue-green uygulamasını kullanıyorsanız ancak doğrulama adımını "bir dakika etrafa tıklama" olarak görüyorsanız, burası onu güvenebileceğiniz bir şeye dönüştüren kısımdır. İki özdeş ortam çalıştırmanın tüm amacı, bunlardan birini gerçekçi koşullar altında doğrulamaktır. Bir sağlık kontrolü zemin, tavan değildir.
TL;DR
Blue-green dağıtım, iki özdeş üretim ortamı çalıştırır ve aralarında bir yönlendiriciyi değiştirir. Trafiği maviden (canlı) yeşile (yeni) geçirmeden önce, yeşile karşı doğrudan tam API test paketinizi çalıştırın. Geçişi, paketin yeşil bir yapısına bağlayın. Apidog CLI ile, aynı test senaryolarını pipeline'ınızdaki yeşil temel URL'ye yönlendirin, herhangi bir doğrulama başarısız olursa dağıtımı durdurun ve ancak o zaman yönlendiriciyi değiştirin. Sağlık kontrolleri bir sürecin çalıştığını doğrular; API testleri sözleşmenin hala geçerli olduğunu doğrular.
Blue-green dağıtım aslında nedir?
Blue-green dağıtım, iki üretim düzeyinde ortamı yan yana tutan bir yayın modelidir. Biri canlı trafiğe hizmet eder (buna mavi diyelim). Diğeri boştadır, bir sonraki sürümü (yeşil) almaya hazırdır. Yeni yapıyı yeşile dağıtırsınız, doğruladıktan sonra tek bir anahtarı (bir yük dengeleyici hedefi, bir DNS kaydı, bir Kubernetes hizmet seçici) değiştirirsiniz, böylece tüm trafik artık yeşile akar. Mavi, bir sonraki yayın için boşta bekleyen yedek haline gelir. Eğer bir şeyler bozulursa, saniyeler içinde maviye geri dönebilirsiniz.
Cazibesi açık. Bakım penceresi yok. Geçiş neredeyse anlık. Ve geri alma, önceki sürüm hala çalıştığı ve hazır olduğu için şimdiye kadarki en ucuzudur. Bunu, yerinde örnekleri değiştirdiğiniz ve kötü bir yapının siz fark edene kadar kullanıcıların bir kısmına hizmet ettiği bir yuvarlanan dağıtımla karşılaştırın.
Ancak bu model, yalnızca yeşil ortam geçiş yaptığınızda gerçekten hazırsa işe yarar. Bu hazırlık kontrolü, çoğu ekibin yeterince yatırım yapmadığı yerdir. Yeşil ortamın açıldığını ve yüzeysel bir `/health` pingini geçtiğini doğrularlar, sonra geçiş yaparlar ve umut ederler. Blue-green dağıtımının şekli, kapsamlı bir kontrolü kolaylaştırır. Yeşil tamamen dağıtılmış ve erişilebilirdir, sadece genel trafik almaz, bu yüzden bunu atlamak için hiçbir mazeret yoktur. Üretimin eksiksiz, izole bir kopyası orada durmuş, test edilmeyi beklemektedir.
Önce daha geniş yayın stratejisi terminolojisini istiyorsanız, sürekli teslimat ve sürekli dağıtım ve sürekli entegrasyon arasındaki farkı açıklayan yazımız blue-green'in nereye oturduğunu gösterir.
Sağlık kontrolü neden bir test değildir?
İşte ekipleri ısıran boşluk. Tipik bir sağlık kontrolü şöyle görünür:
# Yük dengeleyici sağlık probu
GET /health -> 200 OK -> hedefi sağlıklı olarak işaretle
Bu uç nokta genellikle sabit kodlanmış bir `{"status":"ok"}` döndürür. Veritabanınıza dokunmaz. Yetkilendirme yapmaz. Gerçek bir kaynağı seri hale getirmez. Bir yapı, her iş uç noktası bir `500` döndürürken, bozuk bir yük ile veya dünkü şemayla bu probu geçebilir.
Bir `/health` pinginin seve seve geçireceği hata modlarını düşünün:
- Çalışmayan bir migrasyon, bu yüzden `GET /orders/{id}` eksik bir sütunda hata verir.
- Yeniden adlandırılmış bir JSON alanı (`user_id` `userId` oldu) her aşağı akış tüketicisini bozar.
- Mobil uygulamanın hala yayınladığı tokenları artık reddeden bir yetkilendirme değişikliği.
- Tarih biçimlendirmesini ISO 8601'den Unix zaman damgasına değiştiren bir bağımlılık sürüm artışı.
- Yeni bir gerekli başlık, göndermeyen her istemci için `400` döndürür.
Bunların hiçbiri sürecin başlamasını durdurmaz. Hepsi, trafiği çevirdiğiniz anda gerçek kullanıcıları bozar. Çözüm daha akıllı bir sağlık kontrolü değildir; uç noktalarınızı istemcilerin yaptığı gibi çağıran, durum kodları, yanıt gövdeleri, şemalar ve gecikme süresi üzerinde doğrulama yapan, sonra geçiş veya başarısızlık bildiren gerçek bir test paketidir. Bu, API sözleşme testinin arkasındaki aynı disiplindir; çalışan hizmetin hala tüketicilerin güvendiği anlaşmaya uygun olduğunu kontrol ediyorsunuz.
Uçtan uca blue-green test iş akışı
İşte inşa ettiğimiz sıra. Yeni adım "yeşili test et" ve bu, dağıtım ile geçiş arasında yer alıyor.
- Yeşile dağıtım. Yeni yapıyı boşta duran ortama itin. Örneğin `https://green.internal.example.com` gibi dahili bir adresten erişilebilir hale gelir, ancak henüz genel trafik ona ulaşmaz.
- Yeşili smoke test et. Yeşile karşı kritik yol isteklerinin hızlı bir alt kümesini çalıştırın. Giriş yapın, temel bir kaynak getirin, bir tane oluşturun. Herhangi biri başarısız olursa, burada durun. Mavi hala kullanıcılara hizmet veriyor ve hiç fark etmedi.
- Tam paketi yeşile karşı çalıştırın. Tüm API test senaryolarınızı (mutlu yollar, hata durumları, yetkilendirme akışları, şema doğrulamaları) yeşil temel URL'ye yönlendirerek yürütün.
- Geçişi kontrol edin. Paket geçerse, devam edin. Herhangi biri başarısız olursa, pipeline durur ve yeşil ortam kaldırılır veya inceleme için bırakılır. Üretime dokunulmaz.
- Anahtarı çevirin. Yönlendiriciyi (yük dengeleyici, DNS veya hizmet seçici) maviden yeşile yeniden yönlendirin.
- Üretimde doğrulayın. Geçişin sorunsuz gerçekleştiğini doğrulamak için geçiş sonrası canlı URL'ye karşı aynı smoke testi çalıştırın.
- Maviyi hazır tutun. Eski ortamı geri alma penceresi için tutun. Eğer geçiş sonrası izleme ters giderse, anında geri dönün.
Püf nokta, 2, 3 ve 6. adımların aynı test tanımlarını kullanmasıdır. Senaryoları bir kez oluşturursunuz ve yalnızca çalıştırıcının hedeflediği temel URL'yi değiştirirsiniz. Bu, bir sonraki kuracağımız yetenektir.
Apidog'da test senaryolarını oluşturma
Herhangi bir şeyi otomatikleştirmeden önce, çalıştırmaya değer bir test paketi oluşturmanız gerekir. Apidog, bunu görsel olarak oluşturmanıza ve sonra hiçbir şeyi yeniden yazmadan komut satırından çalıştırmanıza olanak tanır. Apidog'u indirin ve dağıttığınız hizmet için bir proje oluşturun.
Bir projenin içinde, mevcut API uç noktalarınızdan test senaryoları oluşturursunuz. Bir senaryo, onaylamalar ve adımlar arasında değişken geçişi olan sıralı bir istek kümesidir. Blue-green hazırlık paketi için, yalnızca tek seferlik pingler değil, gerçek istemcilerin yaptıklarını yansıtan senaryolar istersiniz.
Bir sipariş hizmeti için pratik bir başlangıç seti:
- Yetkilendirme akışı: Geçerli kimlik bilgileriyle `POST /auth/login`, `200` doğrula, taşıyıcı tokenı bir değişkene çıkar, sonraki her istekte kullan.
- Okuma yolu: Token ile `GET /orders`, `200` doğrula, yanıtın bir dizi olduğunu doğrula, her öğenin `id`, `status` ve `total` içerdiğini doğrula.
- Tek kaynak: `GET /orders/{id}`, şemanın OpenAPI tanımınızla eşleştiğini doğrula, `total`'ın sıfırdan büyük bir sayı olduğunu doğrula.
- Yazma yolu: Geçerli bir gövde ile `POST /orders`, `201` doğrula, döndürülen `id`'nin boş olmadığını doğrula, sonra kalıcılığını onaylamak için o yeni id'yi `GET` ile geri al.
- Negatif durumlar: Geçersiz bir token ile `GET /orders/{id}`, `401` doğrula. Eksik gerekli bir alan ile `POST /orders`, `400` doğrula.
Sağlık kontrolünün kaçırdığı hataları yakalamak için iki özellik en önemlidir. Birincisi, şema doğrulamaları: Apidog, bir yanıtı o uç nokta için JSON Şemasına veya OpenAPI tanımına göre doğrulayabilir, böylece yeniden adlandırılmış veya yeniden tiplendirilmiş bir alan üretime sızmak yerine testi başarısız kılar. İkincisi, belirli değerler, başlıklar ve yanıt süresi üzerindeki yanıt doğrulamaları, böylece ince kaymayı yakalarsınız: bir tarih biçimi değişikliği, beklediğiniz yerde `null`, bir gecikme gerilemesi.
Ana tasarım kararı ortam yönetimidir. İsteklerinize `https://blue.example.com` adresini sabit kodlamayın. Temel URL için bir ortam değişkeni tanımlayın ve her yerde `{{baseUrl}}` olarak referans verin. Apidog'da ortamları (Üretim, Yeşil, Yerel) kurar ve etkin olanı değiştirirsiniz veya çalışma zamanında CLI'dan temel URL'yi geçersiz kılarsınız. Bu, ortam ve sır yönetimi olan bir API istemcisi kılavuzumuzda ele alınan aynı ortam ve sırlar disiplinidir; testleriniz mavi ve yeşil arasında aynı kalır, yalnızca hedef değişir.
Bu senaryoları tek bir çalıştırılabilir birime bağlamak isterseniz, Apidog'un test paketleri birden fazla senaryoyu gruplandırır, böylece tek bir komut tüm hazırlık kontrolünü çalıştırır.
Paketi komut satırından çalıştırma
Masaüstü uygulaması senaryoları oluşturduğunuz ve hata ayıklaması yaptığınız yerdir. CLI, pipeline'ınızda yeşil ortama karşı onları çalıştıran şeydir. npm ile yükleyin; Node.js v16 veya üzeri gereklidir:
npm install -g apidog-cli
Çalıştırıcı, bir CI yapılandırmasından bir test senaryosu yürütür. Apidog'da, bir test senaryosu için bir CI yapılandırması oluşturursunuz, bu size bir erişim tokenına bağlı bir çalıştırma komutu verir. Temel şekil:
apidog run "https://api.apidog.com/api/v1/api-test/ci-config/<config-id>/detail?token=<token>" \
-r html,cli \
--out-file green-readiness
`-r` bayrağı raporcuları seçer. `cli` sonuçları terminale yazdırır, böylece pipeline logunuz hangi doğrulamanın başarısız olduğunu tam olarak gösterir. `html`, dağıtımı inceleyen herkes için bir yapı yapıtı olarak arşivleyebileceğiniz kendi kendine yeten bir rapor yazar. Sonuçları başka bir araca beslemek istediğinizde bir JSON raporcusu da vardır. `--out-file` bayrağı çıktıyı adlandırır, böylece her çalıştırma bir yapıya izlenebilir olur.
Paketi özellikle yeşile işaret etmek için, çalıştırıcı bir ortam bayrağını kabul eder, böylece aynı senaryo farklı hedeflere karşı çalışır:
# Geçişten önce yeşil (boşta) ortamı test et
apidog run "<ci-config-url>" \
--environment <greenEnvironmentId> \
-r cli,html \
--out-file green-pre-switch
Ayrıca, her şeyi repo'da tutmayı ve yapılandırmayı getirmek için ağ çağrısı yapmaktan kaçınmayı tercih ettiğinizde, dışa aktarılmış senaryo dosyalarından tamamen çalıştırmaları yönlendirebilirsiniz:
apidog run --exported-data ./tests/orders-readiness.json \
--variables ./tests/green.variables.json \
-r cli
Çalıştırıcının ve pipeline bağlamındaki seçeneklerinin daha derinlemesine bir turu için, CI/CD'de API testlerini nasıl otomatikleştireceğinizi görün. Blue-green için önemli olan davranış çıkış kodudur: bir doğrulama başarısız olduğunda, CLI sıfır olmayan bir değerle çıkar. Bu tek gerçek, geçişi engellemenizi sağlar. Sıfır olmayan bir çıkış, anahtar adımı asla çalışmadan pipeline'ı durdurur.
Bir GitHub Actions pipeline'ına bağlama
İşte bir dağıtım iş akışındaki doğrulama adımı. Bu, daha önceki bir işin yapıyı zaten yeşile dağıttığını ve yeşilin çalıştırıcıdan erişilebilir olduğunu varsayar. İş, yeşili test eder ve yalnızca geçen bir çalıştırma, sonraki işin geçişi gerçekleştirmesine izin verir.
name: deploy-blue-green
on:
push:
branches: [main]
jobs:
deploy-green:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Yapıyı yeşil ortama dağıt
run: ./scripts/deploy-green.sh
# yeşil artık https://green.internal.example.com adresinden erişilebilir
test-green:
needs: deploy-green
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Apidog CLI'yi yükle
run: npm install -g apidog-cli
- name: Hazırlık paketini yeşile karşı çalıştır
run: |
apidog run "${{ secrets.APIDOG_CI_CONFIG_URL }}" \
--environment "${{ vars.GREEN_ENV_ID }}" \
-r cli,html \
--out-file green-readiness
- name: HTML raporunu arşivle
if: always()
uses: actions/upload-artifact@v4
with:
name: green-readiness-report
path: ./green-readiness.html
switch-traffic:
needs: test-green # sadece test-green geçtiyse çalışır
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Yönlendiriciyi maviden yeşile çevir
run: ./scripts/switch-to-green.sh
- name: Geçiş sonrası üretim URL'sini smoke test et
run: |
npm install -g apidog-cli
apidog run "${{ secrets.APIDOG_SMOKE_CONFIG_URL }}" \
--environment "${{ vars.PROD_ENV_ID }}" \
-r cli
Bağımlılık zinciri sizin için engellemeyi yapar. `switch-traffic` `needs: test-green` olarak listeler, bu nedenle hazırlık paketi başarısız olursa, geçiş işi asla başlamaz. Yeşil boşta kalır, mavi hizmet vermeye devam eder ve aşağı akışta hiç kimse etkilenmez. Yapıt yüklemesindeki `if: always()` demek, bir hata durumunda bile HTML raporunu alırsınız, ki tam da o zaman onu okumak istersiniz.
CI yapılandırma URL'sini ve tokenını asla doğrudan değil, depo sırları olarak saklayın. Ortam ID'leri hassas olmadıkları için depo değişkenleri olarak yaşayabilir. Ekibiniz GitLab, Jenkins, CircleCI veya Azure Pipelines üzerinde çalışıyorsa, yapı aynıdır: sıfır olmayan bir değerle çıkan bir test aşaması, geçiş aşamasını engeller. GitHub Actions'ta API testlerini otomatikleştirme kılavuzumuz, çalıştırıcı kurulumunu daha ayrıntılı olarak kapsar ve aynı model bu platformların herhangi birine aktarılır.
Önce smoke test, sonra tam paket
Tüm paketi yeşile karşı çalıştırmak doğru bir engeldir, ancak on iki dakikalık bir çalıştırmanın sekizinci dakikasında tamamen bozuk bir yapı keşfetmek istemezsiniz. Doğrulamayı iki geçişe ayırın.
Smoke test, kritik yolu kapsayan üç ila beş isteklik küçük bir senaryodur. Giriş yapın, bir kaynak okuyun, bir tane oluşturun, geri okuyun. İlk bunu çalıştırın. Yeşil bunları yapamıyorsa, tam paket zaman kaybıdır ve hızlıca başarısız olmalısınız. Bunu otuz saniyenin altında tutun.
Tam paket sadece smoke test geçerse çalışır. Geniş kapsam burada yaşar: her uç nokta, hata durumları, uç durumlar, her yanıtta şema doğrulaması, yetkilendirme permütasyonları, sayfalama, hız sınırlaması başlıkları. Daha yavaştır ve sorun değil, çünkü gerçek kullanıcılardan önceki son engeldir.
Bu iki aşamalı yaklaşım, test senaryosu ve test durumu düşüncesinin arkasındaki aynı mantıktır: smoke senaryo hızlı bir güven sinyalidir, tam paket kapsamlı kapsama sağlar. Her ikisi de aynı yeşil temel URL'yi işaret eder; sadece ne kadarını kapsadıkları ve ne zaman çalıştıkları farklıdır.
Test verileri hakkında bir not. Yeşil bir üretim ortamıdır, bu nedenle yazma yolu testlerinizin ne oluşturduğu konusunda dikkatli olun. Ya yazma testlerini kayıtlarını temizlediğiniz özel bir test hesabına yönlendirin ya da veri katmanı yükseltilmeden önce hazırlık veritabanı tarafından desteklenen yeşil bir örneğe karşı çalıştırın. Üretim verilerini kirletmeden davranışı doğrulamak, yürümeniz gereken çizgidir ve bunu tasarlarken bir sandbox ve test ortamı arasındaki farkı anlamaya değer.
Tüm amacı bozan yaygın hatalar
Ekipler blue-green'i benimser ve yine de bozukluk gönderir. Genellikle bunlardan biridir.
- Yeşil yerine maviyi test etmek. Paketiniz canlı URL'yi işaret ediyorsa, yayınlamak üzere olduğunuz sürümü değil, zaten üretimde olan sürümü test ediyorsunuzdur. Geçişten önce her zaman yeşil temel URL'yi açıkça hedefleyin.
- Yalnızca durum kodlarını kontrol etmek. Yanlış gövdeyle gelen bir `200` bile bozuk bir yanıttır. Yalnızca HTTP durumunu değil, yük şeklini ve anahtar değerleri doğrulayın. Şema doğrulamaları, alan yeniden adlandırmalarını ve tip değişikliklerini yakalayan şeydir.
- Negatif durumları atlamak. Geçersiz bir token için `200` döndüren bir yapı, mutlu yol testinin asla yakalayamayacağı bir güvenlik gerilemesidir. Engellemeye `401`, `403` ve `400` durumlarını dahil edin.
- Geri alma disiplini yok. Blue-green'in süper gücü anında geri almadır, ancak yalnızca maviyi hazır tutarsanız. Yeşil canlıya geçtiği anda onu kaldırmayın. İzleme pencereniz boyunca tutun.
- Test isteklerinde sabit kodlanmış URL'ler. Temel bir URL bir isteğe eklendiği an, aynı paketi yeşil ve maviye karşı çalıştırma yeteneğini kaybetmiş olursunuz. Host için her zaman bir ortam değişkeni kullanın.
- Sağlık kontrolünü engel olarak görmek. Tüm makale, tek bir cümlede. Prob, yük dengeleyiciye bir sürecin var olduğunu söyler. API testleriniz ise sözleşmenin geçerli olduğunu söyler.
Blue-green ve canary: testin yeri
Blue-green, tek sıfır kesinti süreli strateji değildir ve test yaklaşımı her biriyle değişir.
| Strateji | Trafik nasıl hareket eder | API testi nerede yer alır |
|---|---|---|
| Blue-green | Hepsi bir anda, maviden yeşile | Geçişten önce yeşile karşı tam paket; engel, geçiş öncesidir |
| Canary | Kademeli olarak, yeni sürüme küçük % | Canary dilimi üzerinde sürekli doğrulamalar; temiz metrikler üzerine yükseltme |
| Rolling | Örnek bazında, yerinde | Örnek başına smoke kontrolleri; dağıtım zaten devam ettiği için engellemesi daha zor |
| Recreate | Eskiyi durdur, yeniyi başlat (kesinti ile) | Pencere sırasında paket çalışır; kesinti bir ödünleşimdir |
Blue-green, dördü arasında en temiz engeli sunar çünkü yeşil, test ettiğinizde tamamen dağıtılmış ve tamamen izole edilmiştir. Sıfır kullanıcı maruziyeti ve tek bir atomik anahtar ile doğrulamak için eksiksiz bir üretim kopyası elde edersiniz. Canary, bu temiz engeli kademeli maruziyetle değiştirir ve canlı izlemeye daha çok güvenir. Çoğu API destekli hizmet için, blue-green ve geçiş öncesi bir paket, bakım penceresi olmadan yüksek güven elde etmenin en basit yoludur.
Bunun gerçek dünya şekli
Bir ödeme API'si çalıştıran bir fintech ekibi, her yayın için blue-green kullanır çünkü kötü bir dağıtım kozmetik bir hata değil, başarısız bir işlemdir. Engelleri, yetkilendirme, idempotentlik anahtarları, para yuvarlama ve webhook imzalarını kapsayan yeşile karşı kırk senaryoluk bir pakettir. Tam çalıştırma yaklaşık altı dakika sürer. Tamamen yeşil olana kadar hiçbir şey üretime ulaşmaz ve HTML raporu denetim izi için her dağıtıma eklenir.
Herkese açık bir API'ye sahip bir SaaS ekibi daha yalın bir sürüm çalıştırır: yeşile karşı on iki senaryoluk bir smoke engel, sonra geçiş, ardından canlı URL'ye karşı geçiş sonrası bir smoke test. Öncelikleri şema kaymasını yakalamaktır, çünkü bir alanın şekli değiştiğinde üçüncü taraf entegrasyonları gürültülü bir şekilde bozulur. Her yanıttaki şema doğrulamaları, engellerinin kalbidir.
Her iki ekip de senaryoları Apidog'da bir kez oluşturur ve her push'ta CLI'dan gözetimsiz çalıştırır. Masaüstü uygulaması, mühendislerin senaryolarda hata ayıklayıp genişlettiği yer olmaya devam eder; pipeline ise aynı senaryoların yayın engeli haline geldiği yerdir.
Sonuç
Blue-green dağıtım, her yayından önce boşta duran, üretimin ücretsiz, tamamen dağıtılmış bir kopyasını size sunar. Bunu sığ bir sağlık probunu kontrol ederek boşa harcamak, ekiplerin sıfır kesinti süreli bir stratejiyle bozukluk göndermesinin en yaygın yoludur. Çözüm, anahtarı çevirmeden önce yeşili bir kullanıcı gibi test etmektir.
Parçalar:
- Gerçek test senaryolarını (yetkilendirme, okuma, yazma, negatif durumlar, şema doğrulamaları) Apidog'da bir kez oluşturun.
- Temel URL için bir ortam değişkeni kullanın, böylece aynı paket yeşil ve maviye karşı değişmeden çalışır.
- Önce hızlı bir smoke test, sonra tam paket, her ikisi de yeşil ortama yönlendirilmiş olarak çalıştırın.
- Pipeline'ınızdaki paketin çıkış kodunu geçişin engeli olarak kullanın, böylece bir hata geçişi engeller.
- İzleme pencereniz boyunca anında geri alma için maviyi hazır tutun.
Bunu bir kez kurun ve her dağıtım otomatik olarak aynı engeli alır. Hazırlık paketinizi oluşturmak, bir CI yapılandırması oluşturmak ve `apidog run` adımını geçiş aşamasından önce pipeline'ınıza eklemek için Apidog'u indirin. İlk gerçek kullanıcınız, ilk gerçek testiniz olmamalıdır.
düğme
Sıkça Sorulan Sorular
Blue-green dağıtım basit terimlerle nedir? İki özdeş üretim ortamı çalıştırmak ve tüm trafiği aralarında değiştirmektir. Biri (mavi) canlı kullanıcılara hizmet ederken, diğeri (yeşil) yeni sürümü alır. Yeşili test eder, sonra tek bir anahtarı çevirerek yeşilin canlı hale gelmesini sağlarsınız. Mavi, anında geri alma hedefi olarak kalır.
Trafiği değiştirmeden önce yeşil ortamı nasıl test ederim? API test paketinizi yeşil ortamın temel URL'sine yönlendirin ve geçiş adımından önce pipeline'ınızda çalıştırın. Apidog CLI ile senaryolarınızı yeşil ortama karşı `apidog run` ile çalıştırın, herhangi bir doğrulama başarısız olursa dağıtımı durdurun ve yalnızca paket geçerse trafiği değiştirin.
Yük dengeleyici sağlık kontrolü neden blue-green için yeterli değil? Bir sağlık kontrolü genellikle tek bir uç noktaya ping atar ve `200` yanıtını doğrular, bu da sadece sürecin çalıştığını kanıtlar. Yeniden adlandırılmış bir JSON alanını, başarısız bir migrasyonu, bozuk bir yetkilendirme akışını veya bir şema değişikliğini yakalamaz. Gerçek bir API test paketi, yanıt gövdeleri, şemalar ve hata durumları üzerinde doğrulama yapar, böylece bir sağlık probunun gözden kaçırdığı hataları yakalar.
Masaüstü uygulamasında oluşturduğum aynı API testlerini CI'da çalıştırabilir miyim? Evet. Apidog'da görsel olarak oluşturduğunuz senaryolar, Apidog CLI'dan değişmeden çalışır. Bir senaryo için bir CI yapılandırması oluşturur, ardından GitHub Actions, GitLab CI, Jenkins veya herhangi bir pipeline'da bu yapılandırmayla `apidog run` çağrısı yaparsınız. CLI, başarısızlık durumunda sıfır olmayan bir değerle çıkar, bu da dağıtımı engellemenizi sağlar.
Test için blue-green ve canary dağıtımı arasındaki fark nedir? Blue-green, tamamen dağıtılmış yeşil ortamı test ettikten sonra tüm trafiği bir kerede değiştirir, bu nedenle engel geçiş öncesidir. Canary, trafiği kademeli olarak küçük bir dilime kaydırır ve o dilimin canlı izlenmesine güvenir. Blue-green, daha temiz bir yayın öncesi test engeli sağlar; canary ise kademeli gerçek dünya maruziyeti sağlar.
Yazma yolu testlerini yeşil üretim ortamına karşı çalıştırmalı mıyım? Verilerle dikkatli olun. Ya kayıtlarını temizlediğiniz özel bir test hesabı kullanın ya da veri katmanı yükseltilmeden önce hazırlık veritabanı tarafından desteklenen yeşil bir örneğe karşı yazma testleri çalıştırın. Amaç, üretim verilerini kirletmeden davranışı doğrulamaktır, bu da bir sandbox ve gerçek bir üretim testi arasındaki çizgidir.
Geçiş öncesi test engeli ne kadar hızlı olmalı? İkiye ayırın. Hızlı başarısızlık için üç ila beş kritik yol isteğinden oluşan bir smoke testi otuz saniyenin altında çalıştırın, ardından tam paketi (her uç nokta, hata durumları, şema kontrolleri) yalnızca smoke test geçerse çalıştırın. Birkaç düzine senaryodan oluşan eksiksiz bir engel genellikle birkaç dakika içinde tamamlanır, bu da bir yayın engeli için kabul edilebilir.