Azure Pipelines'ta Otomatik API Testleri Adım Adım Nasıl Çalıştırılır

API'niz dizüstü bilgisayarınızda çalışıyor. Yerel test istemcinizdeki her kontrolü geçiyor. Sonra bir ekip arkadaşı bir dalı birleştiriyor, dağıtım yapılıyor ve eskiden 200 dönen bir uç nokta üretimde 500 dönmeye başlıyor. Kimse bunu fark etmedi, çünkü kimse o dalda testleri çalıştırmadı. Onları bir makinede, bir kez, elle çalıştırdılar.

"Testler mevcut" ile "her değişiklikte testler çalışıyor" arasındaki bu boşluk, bir CI hattının kapattığı şeydir. Kodunuz zaten Azure Repos veya GitHub'da yaşıyorsa ve ekibiniz Azure DevOps üzerinde geliştirme yapıyorsa, Azure Pipelines bu güvenlik ağını kurmak için doğal bir yerdir. Zor kısım nadiren YAML'dır. API test paketinizi, doğru ortamda, yeni dağıtılmış bir yapıya karşı, başsız bir şekilde çalıştırabilecek ve bir şeyler bozulduğunda yapıyı yüksek sesle başarısız edebilecek bir formata sokmaktır.

Kısaca

• Azure Pipelines, her commit veya PR'da API testlerinizi otomatik olarak çalıştırır, böylece regresyonlar dağıtımdan önce yakalanır.
• Test senaryolarınızı Apidog'da görsel olarak oluşturun, ardından test komut dosyalarını elle yazmak ve sürdürmek yerine Apidog CLI (apidog-cli) ile CI'da çalıştırın.
• Pipeline'ın dört şeye ihtiyacı vardır: aracıya kurulu Node.js, kurulu CLI, bir bağlantı veya dışa aktarılmış dosya aracılığıyla erişilebilir test senaryonuz ve bir gizli anahtar olarak depolanmış bir erişim belirteci.
• CLI'dan sıfır olmayan bir çıkış kodu, derlemeyi otomatik olarak başarısız kılar. Size gerçek bir geçit sağlayan da budur.
• HTML veya JUnit raporunu bir pipeline artefaktı olarak yayınlayın (veya PublishTestResults aracılığıyla), böylece herkes logları açmadan geçme/kalma durumunu okuyabilir.

"Azure Pipelines'da otomatik API testi" aslında ne anlama geliyor

Azure Pipelines, Azure DevOps içindeki CI/CD hizmetidir. Deponuzda bulunan bir YAML dosyasında (azure-pipelines.yml) bir derlemeyi tanımlarsınız ve Azure, bir tetikleyici her çalıştığında (bir push, bir pull request, bir zamanlama veya manuel bir çalıştırma) bu dosyayı barındırılan veya kendi barındırdığı bir aracı üzerinde çalıştırır.

API testi için işin şekli basittir:

1. Bir aracı (temiz bir VM) başlatın.
2. Test çalıştırıcınızın ihtiyaç duyduğu her şeyi kurun.
3. Hedef bir ortama karşı API testlerini çalıştırın.
4. Sonuçları raporlayın ve bunlara göre derleme durumunu ayarlayın.

İnsanların takıldığı detay 3. adımdır. Yerel bir API istemcisi etkileşimlidir; "Gönder"e tıklarsınız, yanıtı gözlemlersiniz, yeşil bir onay işareti okursunuz. Bir pipeline'ın tıklayacak veya gözlemleyecek kimsesi yoktur. Aynı iddiaları bir insan ve bir GUI olmadan çalıştırmanın bir yoluna ihtiyacınız var. Komut satırı çalıştırıcının var olmasının tüm nedeni budur.

Buradaki CI kavramları hakkında daha geniş bir başlangıç isterseniz, ilk pipeline'ınızı kurmadan önce sürekli entegrasyon, sürekli teslimat ve sürekli dağıtım arasındaki farkı hızlıca okumakta fayda var.

Neden Apidog'da testler tasarlamalı ve CLI ile çalıştırmalı

API testlerini ham kodla yazabilirsiniz. Bir dil seçin, bir HTTP kütüphanesi ve bir iddia çerçevesi kullanın, istek gövdelerini elle oluşturun, yanıtları ayrıştırın, kimlik doğrulama belirteçlerini yönetin ve tüm bunları her sprint'te değişen bir API ile senkronize tutun. Ekipler bunu yapıyor. Ayrıca bakımına orantısız miktarda zaman harcıyorlar.

Apidog farklı bir yol izler. Test senaryolarını görsel olarak oluşturursunuz: istekleri zincirleyin, bir yanıttaki verileri bir sonraki isteğe geçirin, durum kodları, başlıklar ve JSON alanları üzerinde iddialar ekleyin ve aynı senaryoyu birden çok veri satırıyla çalıştırın. Apidog zaten API tanımlarınızı barındırdığı için testler spesifikasyona yakın kalır. Şema değiştiğinde, sapmayı üretimde keşfetmek yerine görürsünüz.

Bu görsel çalışmayı CI'a bağlayan parça, npm üzerinde yayınlanan bir komut satırı çalıştırıcısı olan Apidog CLI'dır. Kayıtlı bir test senaryosunu başsız olarak yürütür ve sonucu yansıtan bir durum koduyla çıkar: her şey başarılı olursa 0, herhangi bir iddia başarısız olursa sıfır olmayan bir kod. Bu çıkış kodu, her CI sisteminin anladığı sözleşmedir. Azure Pipelines bunu okur ve derlemenin yeşil mi yoksa kırmızı mı olduğuna karar verir. GUI'de bir kez tasarlarsınız ve aynı senaryo pipeline'da değişmeden çalışır.

Bu, GitHub Actions, GitLab CI ve Jenkins için de çalışan aynı modeldir. Azure Pipelines, aynı CLI komutu için sadece başka bir barındırıcıdır; bu da ekibiniz platformları değiştirdiğinde bilginin aktarılacağı anlamına gelir.

Ön Koşullar

• En az bir test senaryosu içeren bir Apidog projesi. Test Senaryoları bölümünü açın, bir senaryo oluşturun, birkaç istek ekleyin ve iddiaları bağlayın. Yerel olarak bir kez çalıştırın ve geçtiğini doğrulayın. Kendi makinenizde güvenilmezse, CI'da da güvenilmez olacaktır.
• Bir Apidog erişim belirteci. CLI, Apidog hesap ayarlarınızdan alınan kişisel bir erişim belirteci ile kimlik doğrulaması yapar. Bunu bir parola gibi ele alın; bir pipeline sırrı olarak saklayacaksınız, asla YAML'da değil.
• Bir depo ile bir Azure DevOps projesi. azure-pipelines.yml dosyanız depo kökünde yer alacaktır.
• Node.js aşinalığı (hafif). CLI Node üzerinde çalışır, bu nedenle aracının Node kurulu olması gerekir. Azure'ın barındırılan aracılarında zaten vardır; sadece bir sürüm seçeceksiniz.
• Erişilebilir bir hedef ortam. Testlerinizin çalışan bir API'ye ulaşması gerekir; bir hazırlık ortamı (staging) URL'si, bir önizleme dağıtımı veya pipeline'ın kendisinin başlattığı bir hizmet. Tetikleyiciyi yazmadan önce buna karar verin.

Hangi hedefe karşı test yapılacağına dair kısa bir not. Her commit'te paketi üretim ortamına karşı çalıştırmak risklidir ve genellikle imkansızdır (üretimde test verisi istemezsiniz). Çoğu ekip CI testlerini bir hazırlık ortamına (staging environment) veya dala özel bir önizleme dağıtımına yönlendirir. Apidog ortamları bunu temiz hale getirir: kendi temel URL'sine ve değişkenlerine sahip bir Staging ortamı tutun ve çalışma zamanında CLI'ye hangisini kullanacağını söyleyin.

Adım 1: Test senaryonuzu çalıştırılabilir bir forma sokun

CLI'nin hangi senaryoyu çalıştıracağını bilmesi gerekir. Apidog size bunu yapmanın iki yolunu sunar.

A Seçeneği: paylaşılan bir çevrimiçi bağlantıdan çalıştırın. Apidog'da test senaryonuzu açın, CLI aracılığıyla çalıştırmayı seçin ve Apidog, senaryoyu ağ üzerinden gösteren bir komut oluşturur. Bu, daha az bakım gerektiren seçenektir: pipeline her zaman senaryonun güncel sürümünü çalıştırır ve test dosyalarını depoya commit etmezsiniz. Dezavantajı ise, pipeline'ın çalışma zamanında bu bağlantının erişilebilir olmasına bağlı olmasıdır.

B Seçeneği: senaryoyu bir dosyaya dışa aktarın ve commit edin. Senaryoyu (ve ortamını) yerel bir dosyaya dışa aktarın, kodunuzla birlikte commit edin ve CLI'yi dosya yoluna yönlendirin. Bu, testi belirli bir commit'e bağlar; yeniden üretilebilirlik sizin için önemliyse istediğiniz budur; çalışan testler tam olarak o commit'teki testlerdir. Dezavantajı ise, senaryo değiştiğinde yeniden dışa aktarmanız gerekmesidir.

Yeni başlayan çoğu ekip için A Seçeneği daha hızlı kurulur. Düzenlenmiş veya denetim ağırlıklı işler için B Seçeneği'nin yeniden üretilebilirliği kazanır. Hızlı değişen özellik dalları için bağlantı tabanlı, yayın dalları için dosya tabanlı olarak karıştırabilirsiniz.

Her iki durumda da, Apidog'un size verdiği tam çalıştırma komutunu not alın. Şuna benzer olacaktır:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t <access-token> \
 -e <environment-id>

En çok güveneceğiniz bayraklar:

• senaryo referansı (çevrimiçi bir bağlantı veya yerel bir dosya yolu),
• kimlik doğrulama için -t / erişim belirteci,
• hangi ortama karşı çalıştırılacağını belirten -e,
• çıkış formatını kontrol etmek için bir raporlayıcı seçeneği (CLI metni, HTML veya makine tarafından okunabilir bir özet),
• senaryonun bir veri kümesi üzerinde döngü yapmasını istediğinizde bir yineleme sayısı.

Apidog'un senaryonuz için oluşturduğu çalıştırma komutuna karşı tam bayrak adlarını doğrulayın; çalıştırıcı, apidog run --help ile kullanımı yazdırır. Bayrakları tahmin etmeyin; Apidog'un size verdiklerini kopyalayın ve gizli anahtarları parametreleştirin.

Adım 2: Önce CLI'nin yerel olarak çalıştığını doğrulayın

Yeni bir aracı asla CI içinde hata ayıklamayın. Pipeline geri bildirim döngüleri yavaştır ve loglar terminalinizden daha gürültülüdür. Önce kendi makinenizde başarılı bir çalıştırma elde edin.

CLI'yi yükleyin:

npm install -g apidog-cli

Ardından senaryonuzu çalıştırın:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t "$APIDOG_ACCESS_TOKEN" \
 -e "<staging-environment-id>"

Üç şeyi kontrol ediyorsunuz:

1. Komut tamamlanır ve bir geçme/kalma özeti yazdırır.
2. Çıkış kodu sonuçla eşleşir. Hemen ardından echo $? komutunu çalıştırın; başarı durumunda 0, başarısızlık durumunda sıfır olmayan bir değer olmalıdır.
3. Ortam doğru çözüldü; istekleriniz kalan yerel bir URL'ye değil, hazırlık ortamınızın (staging) URL'sine ulaştı.

Bu çıkış kodu kontrolü göründüğünden daha önemlidir. Bir iddia başarısız olsa bile CLI 0 ile çıkarsa, pipeline'ınız bozuk kodda yeşile döner, ki bu hiç test yapmamaktan daha kötüdür. Bir kez bir hatayı zorlayın (bir iddiayı kasıtlı olarak bozun) ve sıfır olmayan bir kod aldığınızı doğrulayın. Ardından iddiayı geri koyun.

Adım 3: Azure Pipelines YAML'sini oluşturun

Deponuzun köküne azure-pipelines.yml adında bir dosya ekleyin. Barındırılan bir Ubuntu aracısı için eksiksiz, çalışan bir başlangıç noktası:

trigger:
 branches:
 include:
 - main
 - develop

pr:
 branches:
 include:
 - main

pool:
 vmImage: ubuntu-latest

variables:
 NODE_VERSION: '20.x'

steps:
 - task: NodeTool@0
 inputs:
 versionSpec: $(NODE_VERSION)
 displayName: 'Install Node.js'

 - script: npm install -g apidog-cli
 displayName: 'Install Apidog CLI'

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'

Üzerinden geçelim:

• trigger, pipeline'ı main ve develop dallarına yapılan her push'ta çalıştırır. Kendi dal adlarınıza göre ayarlayın.
• pr, main hedeflenen pull request'lerde çalıştırır. Bu, bozuk bir dalın birleşmesini durduran geçittir.
• pool / vmImage, Microsoft tarafından barındırılan bir Ubuntu aracısı seçer. Yönetilecek altyapı yok.
• NodeTool@0, belirli bir Node sürümünü kurar, böylece çalıştırmalarınız yeniden üretilebilir olur.
• Kurulum adımı, her çalıştırmada CLI'yi taze olarak çeker. Daha hızlı derlemeler için node_modules'ı önbelleğe alabilir veya bir sürümü sabitleyebilirsiniz, ancak basit başlayın.
• Çalıştırma adımı önemlidir. Herhangi bir iddia başarısız olursa, apidog run sıfır olmayan bir kodla çıkar, komut dosyası görevi başarısız olur ve tüm derleme kırmızıya döner.

$(...) referansları pipeline değişkenleridir. SCENARIO_ID, STAGING_ENV_ID ve özellikle APIDOG_ACCESS_TOKEN bir sonraki adımdan gelir, buraya sabit kodlanmaz.

Adım 4: Gizli anahtarları doğru şekilde saklayın

Erişim belirteciniz asla YAML'da düz metin olarak bulunmamalıdır. Depoya okuma erişimi olan herkes onu görür ve bu, Apidog projenize erişim yetkisi verir.

1. Azure DevOps'ta pipeline'ınızı açın ve Düzenle'yi, ardından Değişkenler'i (veya paylaşılan bir değişken grubu için Kütüphane'yi) seçin.
2. APIDOG_ACCESS_TOKEN'ı ekleyin ve belirteci yapıştırın.
3. Kilit simgesini açıp kapatarak gizli olarak işaretleyin. Azure onu şifreler ve loglarda maskeler.

Gizli değişkenler otomatik olarak kabuk ortamına enjekte edilmez; onları adımda açıkça eşleştirirsiniz. Gizli anahtarı env aracılığıyla geçirmek için çalıştırma adımını güncelleyin:

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

SCENARIO_ID ve STAGING_ENV_ID gizli olmak zorunda değildir; okunabilirlik için onları düz değişkenler olarak ele alın veya pipeline'lar arasında yeniden kullandığınız bir değişken grubuna taşıyın. Çok sayıda gizli anahtarı yöneten ekipler için, rotasyonun tek bir yerde gerçekleşmesi için değişken grubunu Azure Key Vault ile destekleyin.

Adım 5: Okunabilir bir test raporu yayınlayın

Kırmızı bir derleme, bir şeylerin bozulduğunu söyler. Size neyin bozulduğunu söylemez. Çözüm, CLI'nin bir rapor yayınlamasını sağlamak ve Azure'ın bunu göstermesidir.

Apidog CLI, sonuçlarını bir rapor dosyasına yazabilir. Onu bir çıktı formatına (insanlar için HTML, Azure'ın yerel test görünümünü istiyorsanız JUnit tarzı XML) ve bir çıktı dizinine yöneltin, ardından bu dizini yayınlayın.

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID) \
 -r html \
 --out-dir $(Build.ArtifactStagingDirectory)/api-report
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

 - task: PublishBuildArtifacts@1
 condition: always()
 inputs:
 pathToPublish: $(Build.ArtifactStagingDirectory)/api-report
 artifactName: api-test-report
 displayName: 'Publish API test report'

Dikkat edilmesi gereken iki şey var. Birincisi, condition: always() yayınlama adımının test adımı başarısız olsa bile çalışmasını sağlar; önemli olan da budur, çünkü bir şeyler bozulduğunda raporu en çok o zaman istersiniz. İkincisi, CLI sürümünüz için tam raporlayıcı bayrağını (-r, --reporter veya benzeri) ve çıktı seçeneğini apidog run --help komutuyla kontrol edin, ardından örneği buna göre ayarlayın.

Sonuçları Azure'ın yerleşik Testler sekmesinde trend grafikleriyle görmek isterseniz, CLI'nin JUnit XML çıktısı vermesini sağlayın ve XML'e işaret eden bir PublishTestResults@2 görevi ekleyin. Bu size sadece tek seferlik bir dosya değil, derlemeler arasında iddia başına geçmişi sunar.

Adım 6: Geçidi gerçek yapın

Pipeline'ı kurmak, onu uygulamakla aynı değildir. Varsayılan olarak, başarısız bir derleme, Azure DevOps'a bunu zorunlu kılmasını söylemediğiniz sürece kimsenin birleştirmesini durdurmaz.

1. Depolar'a, ardından Dallar'a gidin, main dalını bulun ve Dal ilkelerini açın.
2. Derleme Doğrulaması ekleyin ve pipeline'ınızı seçin.
3. Zorunlu olarak ayarlayın.

Artık API test pipeline'ı geçene kadar bir pull request main dalına birleşemez. Çalışan testler ile koruyan testler arasındaki fark budur. Bunu açana kadar bir gösterge panonuz var; sonrasında ise bir geçidiniz.

Gerçekçi veri odaklı bir örnek

Tek atımlık senaryolar bariz kırılmaları yakalar. Gerçek API'lerin birçok girdi ile aynı uç noktanın test edilmesine ihtiyacı vardır; geçerli yükler, uç durumlar, 500 yerine 400 döndürmesi gereken yanlış biçimlendirilmiş istek.

Apidog, veri odaklı testi destekler: bir senaryoya bir CSV veya JSON veri kümesi ekleyin ve her satır için bir kez çalışır, satırın değerlerini isteklere ve iddialara yerleştirir. Örneğin, bir oturum açma senaryosu, geçerli bir kullanıcı, yanlış bir parola, kilitli bir hesap ve boş bir gövde için satırları çalıştırabilir, her biri kendi beklenen durum koduna sahip olur.

Pipeline'da komutun şeklinde hiçbir şey değişmez; aynı senaryoya karşı hala apidog run çağrısı yaparsınız. Veri kümesi senaryo ile birlikte gelir, bu nedenle tek bir CLI çağrısı her satırı kapsar. Apidog'da yeni bir uç durum eklediğinizde, bir sonraki pipeline çalıştırması hiçbir YAML düzenlemesi olmadan bunu alır. Test mantığını pipeline yerine araçta tutmanın getirisi budur: kapsamınız büyürken pipeline sıkıcı kalır.

Yaygın sorunlar ve bunları nasıl düzelteceğiniz

• Bir uç nokta bozuk olmasına rağmen derleme geçiyor. Neredeyse her zaman bir çıkış kodu sorunudur. CLI'nin başarısızlık durumunda sıfır olmayan bir değer döndürdüğünü doğrulayın (Adım 2) ve bunu yutmadığınızdan emin olun; sondaki bir || true veya farklı bir komutla biten çoklu komutlu bir komut dosyası hatayı maskeleyecektir. apidog run çağrısını komut dosyası bloğundaki son anlamlı komut olarak tutun.
• apidog: command not found. Kurulum adımı çalışmadı, test adımından sonra çalıştı veya aracının kabuğunun göremediği bir yola kuruldu. npm install -g apidog-cli komutunun çalıştırma adımından önce göründüğünü doğrulayın. Bazı kendi barındırılan aracılarda genel npm bin PATH üzerinde değildir; bunun yerine yerel olarak kurun ve npx apidog run ... aracılığıyla çağırın.
• CI'da kimlik doğrulama başarısız oluyor ancak yerel olarak çalışıyor. Gizli anahtar adıma ulaşmıyor. Gizli değişkenler env: aracılığıyla eşleştirilmelidir (Adım 4); otomatik olarak enjekte edilmezler. Ayrıca belirtecin sondaki bir yeni satır veya tırnak işaretiyle yapıştırılmadığını kontrol edin.
• Testler yanlış ortama ulaşıyor. -e değeri yanlış Apidog ortamına işaret ediyor veya ortamın temel URL'si hala localhost'a referans veriyor. Değişkenleri erişilebilir, CI güvenli URL'lere çözümlenen özel bir Staging ortamı tutun ve kimliğini açıkça CLI'ye iletin.
• Çalıştırmalar arasında rastgele geçme/kalma. Genellikle paylaşılan değiştirilebilir durum; bir kayıt oluşturan bir test ve daha sonra onunla çakışan bir çalıştırma. Senaryoları kendi kendine yeterli hale getirin: ihtiyacınız olanı oluşturun, onaylayın, sonra temizleyin veya yeniden çalıştırmaların dünün verilerine takılmaması için çalıştırma başına benzersiz tanımlayıcılar kullanın. Başka bir araçtan geçiş yapıyorsanız, Newman olmadan CI'da API testleri nasıl çalıştırılır makalesindeki desenler aynı izolasyon tuzaklarını kapsar.

Temel Bilgilerin Ötesinde

• Gecelik bir çalıştırma planlayın. Veri değişikliklerinden veya üçüncü taraf API kaymalarından kaynaklanan sapmaları kimse kod göndermediği günlerde bile yakalamak için, hazırlık ortamına (staging) karşı tüm paketi sabah 2'de çalıştıracak bir schedules tetikleyicisi ekleyin.
• Hızlı ve yavaş paketleri ayırın. Hızlı geri bildirim için her PR'da hızlı bir smoke senaryosu çalıştırın ve main'e yapılan birleşmelerde tam regresyon paketini çalıştırın. İki pipeline tanımı, aynı CLI.
• Birden çok ortamı bir matriste test edin. Aynı senaryoyu hazırlık ortamına (staging) ve bir ön üretim ortamına paralel olarak, her biri kendi ortam kimliğiyle çalıştırmak için bir pipeline matrisi kullanın.
• Sadece birleştirmeyi değil, dağıtımı da kontrol edin. Çok aşamalı bir pipeline'da API test aşamasını dağıtım aşamanızdan önce koyun, böylece başarısız bir test sadece birleştirmeyi değil, sürümü de durdurur.

Bunların her biri, aynı temele küçük birer eklemedir: temiz bir şekilde çıkan bir CLI ve çıkış koduna saygı duyan bir pipeline.

Sıkça sorulan sorular

• Azure Pipelines'da API testleri çalıştırmak için herhangi bir kod yazmam gerekiyor mu? Hayır. Test senaryolarını Apidog'da görsel olarak oluşturursunuz ve pipeline bunları tek bir CLI komutuyla çalıştırır. Tek "kod", bir konfigürasyon olan azure-pipelines.yml dosyasının kendisidir, test mantığı değildir. Tamamen komut dosyası tabanlı testleri tercih ediyorsanız, bunu hala yapabilirsiniz, ancak bu iş akışının amacı bunu atlamaktır.
• Mevcut Postman koleksiyonlarımı Azure Pipelines'da çalıştırmak mümkün mü? Evet, genellikle Newman veya benzeri bir çalıştırıcı ile yapabilirsiniz. Seçenekleri değerlendiriyorsanız, Apidog Postman koleksiyonlarını doğrudan içe aktarır, böylece mevcut testleri getirebilir ve ayrı bir araç zinciri sürdürmek zorunda kalmadan aynı CLI aracılığıyla çalıştırabilirsiniz. Karşılaştırma için Newman olmadan CI'da API testleri nasıl çalıştırılır makalesine bakın.
• Testler nereyi hedeflemeli; hazırlık ortamı (staging) mı yoksa üretim mi? Neredeyse her zaman hazırlık ortamı veya dala özel bir önizleme ortamı. Üretim ortamına karşı yazma ağırlıklı testler çalıştırmak gerçek verileri kirletir ve gerçek yan etkilere neden olabilir. Güvenli temel URL'lere sahip, CI için özel bir Apidog ortamı tutun ve kimliğini -e ile CLI'ye iletin.
• Pipeline bir testin başarısız olduğunu nasıl anlar? Çıkış kodu aracılığıyla. apidog run, her iddia geçtiğinde 0, herhangi biri başarısız olduğunda ise sıfır olmayan bir kod döndürür. Azure Pipelines, sıfır olmayan bir çıkışta komut dosyası görevini başarısız kılar, bu da derlemenin başarısız olmasına neden olur. Geçide güvenmek için bunu bir kez yerel olarak echo $? ile doğrulayın.
• Bu, sadece YAML değil, Azure DevOps Klasik (UI) pipeline'ları ile de çalışıyor mu? Evet. Aynı adımlar geçerlidir; bir "Node Kullan" görevi, npm install -g apidog-cli çalıştıran bir komut satırı görevi ve apidog run ... çalıştıran başka bir komut satırı görevi ekleyin. YAML, deponuzda yaşadığı ve sürüm kontrolü altında olduğu için önerilir, ancak çalıştırıcı adımların nasıl tanımlandığını umursamaz.
• Microsoft tarafından barındırılan bir aracı yerine kendi barındırdığım bir aracı kullanabilir miyim? Evet. Kendi barındırılan aracılar aynı şekilde çalışır; sadece Node.js'nin kurulu olduğundan ve genel npm bin'in aracının PATH'inde olduğundan emin olun veya CLI'yi npx aracılığıyla çağırın. Kendi barındırılan aracılar, hazırlık ortamı API'nizin yalnızca özel bir ağ içinden erişilebilir olduğu durumlarda kullanışlıdır.

Özet

Yeşil bir CI derlemesi, kodun derlendiği anlamına gelmekle kalmayıp, API'nizin gerçekten çalıştığı anlamına gelmelidir. Azure Pipelines'da buraya ulaşmak dört adıma indirgenir: Apidog'da gerçek test senaryoları tasarlayın, bunları Apidog CLI ile başsız olarak çalıştırın, çıkış kodunun derleme durumunu belirlemesine izin verin ve birleşme gerçekleşmeden önce derlemenin geçmesini zorunlu kılın. Bu döngü çalışmaya başladığında, her push, en dikkatli ekip arkadaşınızın vereceği aynı incelemeyi otomatik olarak, her seferinde alır.

Bunun sürdürülebilir kalmasının nedeni ayrılıktır. Test mantığı, API spesifikasyonunuza yakın ve genişletilmesi kolay olan Apidog'da yaşar. Pipeline ince bir sarmalayıcı olarak kalır; kurulum, çalıştırma, raporlama. API'niz büyüdüğünde, araca senaryolar ve veri satırları eklersiniz ve pipeline, düzenleme yapmadan tek işini yapmaya devam eder.

Kurmaya hazır mısınız? Apidog'u indirin, bir test senaryosu oluşturun, CLI çalıştırma komutunu alın ve azure-pipelines.yml dosyanıza bırakın. Bir sonraki regresyonunuz bir müşteri yerine bir makine tarafından yakalanır.