Otomatik API Testlerini Bamboo CI'da Adım Adım Çalıştırma

Derlemeniz yeşil. Birim testleri geçiyor, JAR paketleniyor, yapıt dağıtılıyor. Sonra ilk gerçek istek hazırlık (staging) API'sine geliyor ve bir alt hizmet (downstream service) 500 hatası döndürüyor çünkü birisi iki commit önce bir yanıt alanını değiştirmiş. Derleme her şeyin yolunda olduğunu söyledi. Değildi. Sadece API'yi hiç kontrol etmemişti.

Çoğu Bamboo CI hattının sahip olduğu boşluk budur. Atlassian Bamboo, kod derlemede, JUnit paketlerini çalıştırmada ve yapıtları göndermede iyidir. Kendi başına yapmadığı şey ise HTTP uç noktalarınızın hala sözleşmenizin vaat ettiği şekilde davrandığını doğrulamaktır. Bu güvenlik ağını istiyorsanız, ardışık düzene (pipeline) otomatik API testlerini bir aşama olarak eklemeniz gerekir. Bu kılavuz, testleri oluşturmak için Apidog'u ve bunları bir Bamboo görevinin içinde çalıştırmak için Apidog CLI'yi kullanarak tam olarak bunun nasıl yapılacağını anlatıyor.

Sonunda, her bir push işleminde uç noktalarınıza ulaşan, durum kodlarını kontrol eden, yanıt gövdelerini şemanıza göre doğrulayan ve bir sözleşme bozulduğu anda derlemeyi başarısız kılan bir Bamboo planına sahip olacaksınız. Kişi başına Postman lisansı yok, elle yazılmış doğrulama (assertion) komut dosyalarını sürdürme derdi yok ve her derlemeye eklenmiş gerçek bir HTML test raporu. Takip etmek isterseniz Apidog'u indirin; CLI parçası ücretsiz ve açık kaynaklıdır.

Düğme

API testleri neden Bamboo'ya aittir, sonrasına değil

Birçok ekip API'lerini manuel olarak veya daha kötüsü, üretimde test eder. Birisi bir sürümden önce kaydedilmiş istek koleksiyonuna tıklar ve yanıtları gözle kontrol eder. Bu, çalışmayana kadar işe yarar. İnsanlar unutur. Sürümler Cuma günü gerçekleşir. Kimsenin tekrar kontrol etmeyi düşünmediği tek uç nokta, bozulan uç noktadır.

CI, bu insan değişkenini ortadan kaldırmak için vardır. Bir derleme sunucusunun tüm amacı, aynı kontrollerin her seferinde aynı şekilde, otomatik olarak ve kimsenin çalıştırmayı hatırlamasına gerek kalmadan çalışmasıdır. Birim testleriniz zaten orada bulunur. Entegrasyon testleriniz de muhtemelen öyledir. API testleri de aynı muameleyi hak eder ve bunun birkaç somut nedeni vardır:

Sözleşmeler sessizce bozulur. Bir arka uç geliştiricisi bir JSON alanını userId'dan user_id'ye yeniden adlandırır. Birim testleri hala geçer çünkü bunlar işlevi test eder, kablo biçimini değil. Mobil ekip üç gün sonra öğrenir. Yanıt gövdesi üzerinde doğrulama yapan bir API testi, bunu aynı derlemede yakalar.
Kimse izlemediğinde durum kodları yalan söyler. 201 Created döndürmesi gereken bir uç nokta, yeniden düzenlemeden sonra 200 OK döndürmeye başlar. İşlevsel olarak yakın, teknik olarak yanlış ve katı bir istemci bunu reddedecektir. Bir ardışık düzen doğrulama işlemi bunu saniyeler içinde işaretler.
Kimlik doğrulama gerilemeleri maliyetlidir. Geçerli kimlik bilgilerinde 401 döndüren yanlış yapılandırılmış bir belirteç yenileme akışı, bir oturum açma ekranını devre dışı bırakan türden bir hatadır. Her derlemede kimlik doğrulamalı bir istek çalıştırmak, kullanıcılarınızdan önce bulmanızı sağlar.
Ortamlar kayar. Hazırlık ortamı (staging) bir yapılandırma değişikliği alır, bir özellik bayrağı döner, bir bağımlılık yükseltilir. Her dağıtımdan sonra hazırlık ortamına karşı aynı API paketini çalıştırmak, ortamın hala sağlıklı olup olmadığını size hemen söyler.

Daha derin bağlam, ekiplerin CI/CD'yi ilk etapta benimsemelerinin aynı nedenidir: sorunları geç kalıp maliyetli ve utanç verici hale gelmeden önce, erken ve ucuza çözülebilecekken yakalamak. API testi, bu stratejinin çoğu ardışık düzenin atladığı katmanıdır.

API testi bir Bamboo planına nasıl uyar?

Adım adım ilerlemeden önce, bunun Bamboo modelinde nerede yer aldığını anlamak faydalı olacaktır. Bamboo, işleri planlar halinde düzenler ve her plan, sırayla çalışan bir veya daha fazla aşama içerir. Her aşama görevleri (job) barındırır ve her görev bir dizi adımdan (task) oluşur. Adımlar gerçek komutlardır: kaynak kodu çekme (checkout), derleme (compile), komut dosyası çalıştırma (run a script).

API testleriniz, bir aşamanın içindeki bir görevin (job) içindeki bir adıma (task) dönüşür. Doğal yerleşim, uygulamanız derlendikten ve bir test ortamına dağıtıldıktan sonra çalışan özel bir aşamadır, çünkü istek gönderecek canlı bir şeye ihtiyacınız vardır. Tipik bir plan şöyle görünür:

Plan: ödemeler-servisi
├── Aşama: Derleme
│   └── Görev: Derle ve Birim Testi Yap
│       ├── Adım: Kaynak Kod Çekme
│       └── Adım: Maven, clean package
├── Aşama: Hazırlık Ortamına Dağıtma
│   └── Görev: Dağıtma
│       └── Adım: Yapıtı hazırlık ortamına dağıt
└── Aşama: API Testleri          <- eklediğiniz kısım
    └── Görev: API Paketini Çalıştır
        ├── Adım: Kaynak Kod Çekme
        ├── Adım: Script, Apidog CLI kur ve çalıştır
        └── Adım: Son, test raporunu yayınla

API Testleri aşamasındaki bir adım sıfır olmayan bir kodla çıkarsa, Bamboo bu aşamayı başarısız olarak işaretler ve tüm derleme kırmızı olur. İstediğiniz davranış tam olarak budur; bozuk bir sözleşme, devam etmemeli, aksine hattı durdurmalıdır.

Bu komut dosyası adımında asıl işi yapan araç, Apidog'da görsel olarak tasarladığınız test senaryolarını çalıştıran bir komut satırı çalıştırıcısı olan Apidog CLI'dır. Testi bir kez, bir GUI'de, kod yazmadan oluşturursunuz ve aynı test terminalinizde ve Bamboo'da değişmeden çalışır. Bu, ekiplerin herhangi bir CI/CD sistemi genelinde API testlerini otomatikleştirmek için kullandığı aynı desendir; Bamboo birçok hedef arasında sadece biridir.

Adım 1: API testlerinizi Apidog'da oluşturun

Testleriniz olmadan CI'da test çalıştıramazsınız. Apidog, testleri tasarladığınız yerdir ve tasarım görseldir, bu nedenle kod yazmayan bir QA mühendisi, bir arka uç geliştiricisinin yapacağı aynı paketi oluşturabilir.

Apidog'u açın ve bir test senaryosu oluşturun. Bir senaryo, yukarıdan aşağıya doğru çalışan, her adımın önceki adımlardan verileri yeniden kullanabildiği sıralı bir API istekleri dizisidir. Bir ödeme hizmeti için gerçekçi bir senaryo şöyle olabilir:

Geçerli kimlik bilgileriyle POST /auth/login isteği gönderin, ardından yanıttan taşıyıcı belirteci (bearer token) çıkarın.
Bu belirteci kullanarak POST /orders isteği gönderin, yeni bir sipariş oluşturun, ardından döndürülen orderId'yi kaydedin.
GET /orders/{orderId} isteği gönderin ve siparişin doğru durumla göründüğünü onaylayın.
Temizlemek için DELETE /orders/{orderId} isteği gönderin.

Her istek için doğrulamalar (assertions) ekleyin. Bu, bir isteği teste dönüştüren kısımdır. Apidog, görsel olarak doğrulama yapmanızı sağlar, komut dosyası gerekmez:

Durum kodu 200 (veya 201, sözleşmenin belirttiği neyse) olmalıdır.
Bir JSON alanı var ve eşleşiyor: $.data.status değeri "pending".
Yanıt, uç noktanın OpenAPI şemasına göre doğrulanır, bu nedenle beklenmeyen herhangi bir alan türü veya eksik bir gerekli özellik adımı başarısız kılar.
Yanıt süresi belirli bir eşiğin altında kalır, örneğin 800ms, böylece yavaş bir gerileme de ortaya çıkar.

Şema tabanlı doğrulamaları belirtmekte fayda var. Apidog şema öncelikli olduğu için, uç noktanızın API tanımında vaat ettiği şekli zaten bilir. Tek bir tıklamayla "bu yanıt kendi şemasına uyuyor" diye doğrulayabilirsiniz ve bu tek kontrol, tek bir satır kod yazmanıza gerek kalmadan, sözleşme kaymalarının, yeniden adlandırılmış alanların, yanlış türlerin, bırakılan özelliklerin tüm bir kategorisine karşı koruma sağlar. Komut dosyası yoğun bir araçtan geliyorsanız, bu bile tek başına birçok bakımı ortadan kaldırır. Bu, Apidog'u API testi için yaygın bir Postman alternatifi yapan aynı görsel doğrulama modelidir.

Çok sayıda senaryonuz varsa, ilgili senaryoları bir test paketinde gruplandırın. Bir paket, birlikte çalıştırabileceğiniz senaryoların bir koleksiyonudur ve CI komutunuzu basit tutar; yirmi senaryoyu listelemek yerine çalıştırıcıyı tek bir pakete yönlendirirsiniz.

Yerel, hazırlık ve üretim ortamları arasında değişen her şey için ortam değişkenleri kullanın: temel URL'ler, kimlik bilgileri, API anahtarları. Apidog'da baseUrl değerini hazırlık ana bilgisayarınıza ayarlanmış bir hazırlık ortamı tanımlayın. Çalışma zamanında CLI'ye hangi ortamı kullanacağını söyleyeceksiniz, böylece tam olarak aynı senaryo Bamboo'da hazırlık ortamına ve dizüstü bilgisayarınızda localhost'a karşı çalışır.

Adım 2: Bir Apidog erişim belirteci oluşturun ve ID'leri alın

Bamboo, bir derleme aracısında (build agent) başsız (headless) olarak çalışır. Bir tarayıcı aracılığıyla Apidog hesabınıza giriş yapamaz, bu nedenle CLI bunun yerine bir erişim belirteci ile kimlik doğrulaması yapar.

Test senaryonuzun içinde, CI/CD sekmesini açın. Erişim belirteci ekle'ye tıklayın, ardından Belirteç Oluştur'a tıklayın. Değeri şimdilik güvenli bir yere kopyalayın; kısa süre içinde bir Bamboo değişkeni olarak saklayacaksınız, bir komut dosyasına yapıştırmayacaksınız. Belirteç, bir derleme aracısının özel projenizin testlerini çekmesine ve çalıştırmasına olanak tanır.

CI/CD sekmesindeyken, Apidog sizin için tam çalıştırma komutunu oluşturur. Sağlayıcı olarak Komut satırı'nı seçin ve test senaryosu ID'niz ve proje ID'niz zaten doldurulmuş olarak doğrudan kopyalayabileceğiniz bir şey yazdırır. Bu kopyalanan komut, Bamboo görevinizin temelidir. Önem verdiğiniz parçalar:

Erişim belirteci: kimlik doğrulama, --access-token olarak iletilir.
Test senaryosu ID'si: -t'den sonraki sayısal ID, hangi senaryonun çalıştırılacağını belirler.
Ortam ID'si: -e'den sonraki sayısal ID, CLI'ye hazırlık ortamına karşı çalışmasını söyler.

Oluşturulan bu komutu elinizin altında tutun. Sonraki adımlar onu Bamboo için uyarlayacaktır.

Adım 3: Belirteci bir Bamboo plan değişkeni olarak saklayın

Bir belirteci asla bir komut dosyası adımına sabit kodlamayın. Plan üzerinde okuma erişimi olan herkes ve derleme günlüklerini okuyan herkes onu görecektir.

Bamboo'da planınıza gidin, Plan Yapılandırması'nı açın ve Değişkenler sekmesini bulun. Yeni bir değişken ekleyin. APIDOG_ACCESS_TOKEN gibi açık bir ad verin ve belirteci değer olarak yapıştırın. Bamboo, adı password, secret veya token içeren değişkenleri maskeler, bu yüzden buna göre adlandırın ve değer günlüklerde ve kullanıcı arayüzünde gizlenir.

Çalışma zamanında Bamboo, plan değişkenlerini komut dosyalarına ortam değişkenleri olarak, önekli ve büyük harfli, noktalar alt çizgiye dönüşerek sunar. APIDOG_ACCESS_TOKEN adlı bir değişken, kabuk görevinize $bamboo_APIDOG_ACCESS_TOKEN olarak erişilebilir. Derleme komut dosyasında her zaman bu referansı kullanacaksınız, asla ham belirteci kullanmayacaksınız.

Aynı hijyen, testlerinizin ihtiyaç duyduğu diğer tüm sırlar için de geçerlidir; veritabanı şifreleri, üçüncü taraf API anahtarları, imzalama sırları. Bunları maskelenmiş Bamboo değişkenleri olarak tanımlayın ve bamboo_ ortam öneki aracılığıyla okuyun.

Adım 4: API testi aşamasını ve bir komut dosyası adımını ekleyin

Şimdi bunu plana dahil edin. Plan Yapılandırması'nda yeni bir aşama ekleyin ve ona API Testleri adını verin. Buna bir görev ekleyin, ardından göreve bu sırayla adımlar ekleyin.

Adım 1, Kaynak Kod Çekme. Testler Apidog'un bulutunda yer alsa da, deponuzu çekmek (checkout) aracıya temiz bir çalışma dizini verir ve herhangi bir yerel veri dosyasını (örneğin CSV yineleme verileri) kodunuzla birlikte işlemenize olanak tanır.

Adım 2, Komut Dosyası. Burası işin kalbidir. Bir Komut Dosyası adımını seçin, yorumlayıcıyı Shell'e (veya /bin/sh) ayarlayın ve satır içi bir komut dosyası gövdesi kullanın. Komut dosyası, Apidog CLI'yi aracıya kurar ve senaryonuzu çalıştırır.

Apidog CLI bir npm paketidir, bu nedenle aracının Node.js v16 veya daha yenisine ihtiyacı vardır. Aracılar zaten Node'a sahipse, kurulum satırını atlayabilirsiniz; değilse, Bamboo'nun yetenekleri veya Docker tabanlı bir aracı aracılığıyla sağlayın. İşte tam bir komut dosyası gövdesi:

#!/bin/sh
set -e

# Apidog CLI'yi aracıya global olarak kur
npm install -g apidog-cli

# Test senaryosunu hazırlık ortamına karşı çalıştır, HTML + CLI raporu çıktıla
apidog run \
  --access-token "$bamboo_APIDOG_ACCESS_TOKEN" \
  -t 637132 \
  -e 358171 \
  -r cli,html \
  --out-dir ./apidog-reports

Gerçek test senaryosu ID'niz için 637132'yi ve hazırlık ortamı ID'niz için 358171'i, Apidog'un 2. adımda oluşturduğu komuttaki değerleri kullanarak değiştirin. Her bir bayrağın ne işe yaradığına dair birkaç not:

--access-token maskelenmiş Bamboo değişkenini okur, böylece sır asla komut dosyasında görünmez.
-t (--test-scenario'nun kısaltması) çalıştırılacak senaryoyu seçer. Bunun yerine tüm bir paketi çalıştırmak için --test-suite <id> kullanın; tüm bir senaryo klasörünü çalıştırmak için -f <folderId> kullanın.
-e (--environment), Apidog'da tanımladığınız hazırlık ortamını seçer, böylece istekler doğru değişkenlerle doğru ana bilgisayara gider.
-r cli,html (--reporters) hem Bamboo derleme günlüğünde göreceğiniz bir konsol raporu hem de bir yapıt olarak yayınlayabileceğiniz bir HTML raporu üretir. CLI burada ayrıca json ve junit formatlarını da destekler.
--out-dir raporların nereye kaydedileceğini kontrol eder. Varsayılan olarak ./apidog-reports'tur; bunu açıkça ayarlamak, yapıt yolunu tahmin edilebilir hale getirir.

En üstteki set -e önemlidir. Kabuğun ilk başarısız komutta çıkmasını sağlar. Apidog CLI, herhangi bir doğrulama başarısız olduğunda zaten sıfır olmayan bir çıkış kodu döndürür ve bu sıfır olmayan kod, Bamboo'ya derlemeyi başarısız kılmasını söyleyen şeydir. Birlikte, bozuk bir API sözleşmesinin günlüklerde gömülü kalmak yerine derlemeyi kırmızıya çevireceğini garanti ederler.

Daha önce API testlerini GitHub Actions'a entegre ettiyseniz, bu size tanıdık gelecektir; çalıştırıcı ve bayraklar aynıdır, sadece YAML-karşı-Bamboo-UI sarmalayıcı farklıdır.

Adım 5: Test raporunu bir Bamboo yapıtı olarak yayınlayın

Kırmızı bir derleme, bir şeyin bozulduğunu söyler. HTML raporu ise *neyin* bozulduğunu söyler. Her derlemenin raporu saklaması için bunu bağlayın.

Aynı görevde, Yapıtlar sekmesine gidin ve yeni bir paylaşılan yapıt tanımlayın:

Ad: Apidog Test Raporu
Konum: apidog-reports
Kopyalama deseni: **/*

Her derlemeden sonra Bamboo, apidog-reports dizinindeki her şeyi toplar ve derleme sonucuna ekler. Herhangi bir derlemeyi açın, Yapıtlar sekmesine gidin ve HTML raporunu indirebilir veya görüntüleyebilirsiniz; istek bazında sonuçlar, çalışan doğrulamalar ve başarısız olan her şey için tam yanıt gövdesi. Bu son kısım, gerçek hata ayıklama zamanından tasarruf etmenizi sağlar. Başarısız olan isteği elle tekrar çalıştırmak yerine, yakalanan yanıtı doğrudan derlemeden okursunuz.

Bamboo içinde daha zengin bir görüntüleme için junit raporlayıcısı da kullanışlıdır. -r listesine junit'i ekleyin, ardından JUnit XML dosyasına işaret eden bir JUnit Ayrıştırıcı (Parser) adımı ekleyin. Bamboo daha sonra birim test sonuçlarınızı gösterdiği gibi, derleme özetinde test sayılarını, geçme/kalma dökümlerini ve başarısızlık eğilimlerini yerel olarak işler.

Adım 6: Çalıştırın ve sonucu okuyun

İlk çalıştırma için planı manuel olarak tetikleyin; Bamboo'da, plan sayfasından Planı Çalıştır'ı seçin. API Testleri aşamasının derleme günlüğünü izleyin. npm'in CLI'yi kurduğunu, ardından Apidog çalıştırma çıktısının akışını, senaryo adını, her isteği, her doğrulamayı ve toplamlarla birlikte son bir özet satırını göreceksiniz.

İki sonuç:

Tüm doğrulamalar geçer. CLI 0 ile çıkar, aşama yeşile döner, derleme başarılı olur ve HTML raporu yine de bir yapıt olarak eklenir, böylece bir kaydınız olur. Güzel. Şimdi bunu otomatik hale getirin; planı ana dalınıza yapılan her committe tetiklenecek şekilde ayarlayın (Plan Yapılandırması, Tetikleyiciler, Depo yoklaması veya bir webhook). Bundan sonra, her push işleminiz API paketinizi sıfır insan müdahalesiyle çalıştırır.

Bir doğrulama başarısız olur. CLI sıfır olmayan bir değerle çıkar, set -e komut dosyasını durdurur, aşama kırmızıya döner ve derleme başarısız olur. Yapıtı açın, başarısız isteği bulun ve yakalanan yanıtı okuyun. Belki bir alan değişti. Belki bir bağımlılık çöktüğü için hazırlık ortamı 502 döndürdü. Her iki durumda da, onu tanıtan committen sonra bir veya iki dakika içinde öğrenirsiniz ki bu, tüm yatırımın karşılığıdır.

Gerçekçi bir konsol özeti şöyle görünür:

┌──────────────┬──────────┬──────────┐
│              │ çalıştırdı │ başarısız │
├──────────────┼──────────┼──────────┤
│   yinelemeler│        1 │        0 │
├──────────────┼──────────┼──────────┤
│     istekler │        4 │        0 │
├──────────────┼──────────┼──────────┤
│   doğrulamalar│       11 │        1 │
└──────────────┴──────────┴──────────┘

  1 doğrulama başarısız oldu:
    GET /orders/{orderId}
      beklenen $.data.status "pending" idi ancak "failed" geldi

Başarısız olan o tek doğrulama, aşamanın var olmasının tüm nedenidir. Temiz bir şekilde derlenen ve her birim testini geçen bir sözleşme gerilemesini yakaladı.

Paketi CI'da güvenilir hale getirme

Güvenilir olmayan bir API testi, hiçbir testten daha kötüdür, çünkü ekibi kırmızı derlemeleri görmezden gelmeye alıştırır. Birkaç alışkanlık, paketi güvenilir tutar.

Test verilerini izole edin. Her çalıştırma, ihtiyacı olanı oluşturmalı ve kendinden sonra temizlemelidir, yukarıdaki oluştur-sonra-sil sipariş akışı gibi. Geçen Salı oluşturulmuş bir kayda bağlı olan testler, o kayıt değiştiği anda bozulacaktır. Asla üretim ortamına karşı değil, özel bir hazırlık veya test ortamına karşı çalıştırın.
Tekrarlamadan kapsam için veri odaklı çalıştırmalar kullanın. Aynı uç noktayı yirmi farklı girişle test etmeniz gerekiyorsa, yirmi senaryo oluşturmayın. --iteration-data path/to/data.csv (veya -d) ile tek bir senaryo kullanın ve CLI bunu her satır için bir kez çalıştırır. CSV'yi deponuza işleyin, böylece kodla birlikte çekilir. Bu, yerel olarak kullanacağınız aynı veri odaklı test modelidir, sadece CI'daki bir dosyadan beslenir.
CLI sürümünü sabitleyin. npm install -g apidog-cli en son sürümü çeker. Tekrarlanabilir derlemeler için bilinen bir sürümü sabitleyin, npm install -g apidog-cli@<sürüm>, böylece bir CLI güncellemesi aynı commite ait iki derleme arasında davranışı sessizce değiştirmez.
Mantıklı zaman aşımları ayarlayın. Asılı kalmış bir uç noktada hızlı başarısız olmak için --timeout-request 10000 ekleyin, böylece derlemenin Bamboo'nun kendi zaman aşımı onu sonlandırana kadar asılı kalmasına izin vermez. Açık bir "istek zaman aşımına uğradı" mesajı, belirsiz bir askıda kalmış derlemeyi yener.
API aşamasında dağıtımları engelleyin. API Testleri aşaması herhangi bir üretim dağıtım aşamasından önce çalıştığı ve başarısız bir aşama planı durdurduğu için, bozuk bir sözleşme üretime ulaşamaz. Bu sıralama sizin sürüm kapınızdır. Bu, sadece derleme yapan bir derleme yerine gerçek bir CI/CD ardışık düzeni oluşturmanın pratik versiyonudur.
Senaryoları hızlı ve odaklanmış tutun. Yirmi dakika süren bir CI paketi her committe çalışmaz; insanlar onu geceliğe taşıyacak ve hızlı geri bildirimi kaybedeceklerdir. Her commite özel paketi kritik yollarınıza, kimlik doğrulamaya, temel CRUD işlemlerine, ödeme akışına odaklayın ve kapsamlı uç durum paketini programlı olarak çalıştırın.

Sonuç

Bamboo sizi zaten derlenmeyen koddan ve geçmeyen birim testlerinden korur. Bir API test aşaması eklemek, bu korumayı hizmetlerinizin aslında ağ üzerinden sunduğu sözleşmelere, yani çoğu "ama yerelde çalışıyordu" olayının gerçekte yaşandığı katmana genişletir.

Kurulum kısa: Apidog'da görsel, şema farkında testler oluşturun, bir erişim belirteci oluşturun, bunu maskelenmiş bir Bamboo değişkeni olarak saklayın ve senaryo ve ortam ID'lerinizle apidog run komutunu çalıştıran bir komut dosyası adımı ekleyin. Raporu bir yapıt olarak yayınlayın, dağıtım aşamanızı bunun arkasına yerleştirin ve her committe planı tetikleyin. Bundan sonrası otomatiktir. Her push API'nizi kontrol eder ve bozuk bir sözleşme, bir kesintiye dönüşmeden önce derlemeyi kırmızıya çevirir.

Apidog'u indirin ve ilk test senaryonuzu oluşturun, ardından oluşturulan CLI komutunu bir Bamboo komut dosyası adımına bırakın. Temiz bir şekilde derlenen bir gerilemeyi ilk yakaladığında, aşama kurulum için harcanan on dakikanın karşılığını vermiş olacaktır.

Düğme