Cara Menjalankan Tes API Otomatis di Azure Pipelines (Langkah demi Langkah)

API Anda berfungsi di laptop Anda. Ia melewati setiap pemeriksaan di klien pengujian lokal Anda. Kemudian rekan tim menggabungkan cabang, penyebaran dilakukan, dan sebuah endpoint yang dulunya mengembalikan 200 mulai mengembalikan 500 di produksi. Tidak ada yang menyadarinya, karena tidak ada yang menjalankan pengujian pada cabang tersebut. Mereka menjalankannya di sebuah mesin, sekali, secara manual.

Kesenjangan antara “pengujian ada” dan “pengujian berjalan di setiap perubahan” inilah yang ditutup oleh pipeline CI. Jika kode Anda sudah ada di Azure Repos atau GitHub dan tim Anda membangun di Azure DevOps, Azure Pipelines adalah tempat alami untuk menempatkan jaring pengaman itu. Bagian yang sulit jarang ada pada YAML. Ini adalah bagaimana membuat rangkaian pengujian API Anda ke dalam bentuk yang dapat dijalankan oleh pipeline secara headless, dengan lingkungan yang tepat, terhadap build yang baru saja disebarkan, dan kemudian menggagalkan build dengan keras ketika ada sesuatu yang rusak.

TL;DR

• Azure Pipelines menjalankan pengujian API Anda secara otomatis pada setiap komit atau PR, sehingga regresi tertangkap sebelum dikirim.
• Bangun skenario pengujian Anda secara visual di Apidog, lalu jalankan di CI dengan Apidog CLI (apidog-cli) alih-alih menulis dan memelihara skrip pengujian secara manual.
• Pipeline membutuhkan empat hal: Node.js terinstal pada agen, CLI terinstal, skenario pengujian Anda dapat dijangkau melalui tautan atau file yang diekspor, dan token akses yang disimpan sebagai rahasia.
• Kode keluar bukan nol dari CLI secara otomatis menggagalkan build. Itulah yang memberi Anda gerbang yang nyata.
• Publikasikan laporan HTML atau JUnit sebagai artefak pipeline (atau melalui PublishTestResults) sehingga siapa pun dapat membaca lulus/gagal tanpa membuka log.

Apa arti sebenarnya dari “pengujian API otomatis di Azure Pipelines”

Azure Pipelines adalah layanan CI/CD di dalam Azure DevOps. Anda menjelaskan sebuah build dalam file YAML (azure-pipelines.yml) yang ada di repositori Anda, dan Azure menjalankan file tersebut pada agen yang dihosting atau di-host sendiri setiap kali sebuah pemicu menyala; sebuah push, sebuah pull request, sebuah jadwal, atau sebuah eksekusi manual.

Untuk pengujian API, pekerjaan ini berbentuk sederhana:

1. Memutar agen (VM yang bersih).
2. Menginstal apa pun yang dibutuhkan test runner Anda.
3. Menjalankan pengujian API terhadap lingkungan target.
4. Melaporkan hasilnya dan mengatur status build berdasarkan hasilnya.

Detail yang membuat orang bingung adalah langkah 3. Klien API lokal bersifat interaktif; Anda mengklik "Kirim", Anda mengamati respons, Anda membaca tanda centang hijau. Pipeline tidak memiliki siapa pun untuk mengklik dan tidak ada siapa pun untuk mengamati. Anda memerlukan cara untuk menjalankan penegasan yang sama tanpa manusia dan tanpa GUI. Itulah seluruh alasan mengapa ada command-line runner.

Jika Anda ingin pengantar yang lebih luas tentang konsep CI di sini, perbedaan antara integrasi berkelanjutan, pengiriman berkelanjutan, dan penyebaran berkelanjutan patut dibaca sekilas sebelum Anda menyiapkan pipeline pertama Anda.

Mengapa merancang pengujian di Apidog dan menjalankannya dengan CLI

Anda bisa menulis pengujian API dalam kode mentah. Pilih bahasa, tarik pustaka HTTP dan kerangka kerja penegasan, buat badan permintaan secara manual, parse respons, kelola token otentikasi, dan jaga semuanya tetap sinkron dengan API yang berubah setiap sprint. Tim melakukan ini. Mereka juga menghabiskan waktu yang tidak proporsional untuk memeliharanya.

Apidog mengambil jalur yang berbeda. Anda membangun skenario pengujian secara visual: rantai permintaan secara bersamaan, meneruskan data dari satu respons ke permintaan berikutnya, menambahkan penegasan pada kode status, header, dan bidang JSON, dan menjalankan skenario yang sama dengan beberapa baris data. Karena Apidog sudah memiliki definisi API Anda, pengujian tetap dekat dengan spesifikasi. Ketika skema berubah, Anda melihat penyimpangan alih-alih menemukannya di produksi.

Bagian yang menghubungkan pekerjaan visual tersebut ke CI adalah Apidog CLI, sebuah command-line runner yang diterbitkan di npm. Ini mengeksekusi skenario pengujian yang disimpan tanpa kepala dan keluar dengan kode status yang mencerminkan hasilnya: 0 jika semuanya berhasil, bukan nol jika ada penegasan yang gagal. Kode keluar itu adalah kontrak yang dipahami oleh setiap sistem CI. Azure Pipelines membacanya dan memutuskan apakah build berwarna hijau atau merah. Anda mendesain sekali di GUI, dan skenario yang sama berjalan tanpa perubahan di pipeline.

Ini adalah model yang sama yang berfungsi untuk GitHub Actions, GitLab CI, dan Jenkins. Azure Pipelines hanyalah host lain untuk perintah CLI yang sama, yang berarti pengetahuan dapat ditransfer jika tim Anda pernah beralih platform.

Prasyarat

Sebelum Anda membangun pipeline, siapkan hal-hal berikut:

• Sebuah proyek Apidog dengan setidaknya satu skenario pengujian. Buka bagian Skenario Pengujian, buat skenario, tambahkan beberapa permintaan, dan lampirkan penegasan. Jalankan sekali secara lokal dan konfirmasikan berhasil. Jika sering gagal di mesin Anda, itu juga akan sering gagal di CI.
• Token akses Apidog. CLI mengautentikasi dengan token akses pribadi dari pengaturan akun Apidog Anda. Perlakukan seperti kata sandi; Anda akan menyimpannya sebagai rahasia pipeline, tidak pernah di YAML.
• Sebuah proyek Azure DevOps dengan repositori. File azure-pipelines.yml Anda akan berada di root repositori.
• Kefasihan Node.js (ringan). CLI berjalan di Node, jadi agen membutuhkan Node yang terinstal. Agen yang dihosting Azure sudah memilikinya; Anda hanya perlu memilih versi.
• Lingkungan target yang dapat dijangkau. Pengujian Anda harus mengenai API yang sedang berjalan; URL staging, penyebaran pratinjau, atau layanan yang dimulai sendiri oleh pipeline. Putuskan mana yang akan digunakan sebelum Anda menulis pemicu.

Catatan singkat tentang target mana yang akan diuji. Menjalankan rangkaian pengujian terhadap produksi pada setiap komit berisiko dan seringkali tidak mungkin (Anda tidak ingin data pengujian masuk ke produksi). Kebanyakan tim mengarahkan pengujian CI ke lingkungan staging atau penyebaran pratinjau per cabang. Lingkungan Apidog membuatnya bersih: pertahankan lingkungan Staging dengan URL dasar dan variabelnya sendiri, dan beri tahu CLI mana yang akan digunakan saat runtime.

Langkah 1: Dapatkan skenario pengujian Anda ke dalam bentuk yang dapat dijalankan

CLI perlu tahu skenario mana yang akan dijalankan. Apidog memberi Anda dua cara untuk memberinya satu.

Opsi A, jalankan dari tautan online bersama. Di Apidog, buka skenario pengujian Anda, pilih untuk menjalankannya melalui CLI, dan Apidog menghasilkan perintah yang menunjuk ke skenario melalui jaringan. Ini adalah opsi dengan perawatan lebih rendah: pipeline selalu menjalankan versi skenario saat ini, dan Anda tidak menyimpan file pengujian ke repositori. Kelemahannya adalah pipeline bergantung pada tautan tersebut agar dapat dijangkau saat runtime.

Opsi B, ekspor skenario ke file dan komit. Ekspor skenario (dan lingkungannya) ke file lokal, komit bersama kode Anda, dan arahkan CLI ke jalur file. Ini mengunci pengujian ke komit tertentu, yang Anda inginkan jika Anda peduli tentang reproduksibilitas; pengujian yang berjalan adalah persis pengujian dalam komit tersebut. Kelemahannya adalah Anda harus mengekspor ulang ketika skenario berubah.

Untuk sebagian besar tim yang baru memulai, Opsi A lebih cepat untuk disiapkan. Untuk pekerjaan yang diatur atau diaudit dengan ketat, reproduktifitas Opsi B lebih unggul. Anda juga dapat mencampur: berbasis tautan untuk cabang fitur yang bergerak cepat, berbasis file untuk cabang rilis.

Bagaimanapun, catat perintah eksekusi yang tepat yang diberikan Apidog kepada Anda. Ini akan terlihat seperti ini:

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

Flag yang paling sering Anda gunakan:

• referensi skenario (tautan online atau jalur file lokal),
• -t / token akses untuk autentikasi,
• -e untuk lingkungan mana yang akan dijalankan,
• opsi reporter untuk mengontrol format output (teks CLI, HTML, atau ringkasan yang dapat dibaca mesin),
• jumlah iterasi ketika Anda ingin skenario mengulang kumpulan data.

Konfirmasikan nama flag yang tepat dengan perintah run yang dihasilkan Apidog untuk skenario Anda; runner mencetak penggunaan dengan apidog run --help. Jangan menebak-nebak flag; salin yang diberikan Apidog kepada Anda dan parameterkan rahasianya.

Langkah 2: Verifikasi CLI berfungsi secara lokal terlebih dahulu

Jangan pernah men-debug alat baru di dalam CI. Loop umpan balik pipeline lambat dan lognya lebih berisik daripada terminal Anda. Dapatkan eksekusi hijau di mesin Anda sendiri terlebih dahulu.

Instal CLI:

npm install -g apidog-cli

Kemudian jalankan skenario Anda:

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

Anda memeriksa tiga hal:

1. Perintah selesai dan mencetak ringkasan lulus/gagal.
2. Kode keluar cocok dengan hasilnya. Jalankan echo $? segera setelahnya; seharusnya 0 saat berhasil dan bukan nol saat gagal.
3. Lingkungan terselesaikan dengan benar; permintaan mencapai URL staging Anda, bukan URL lokal yang tersisa.

Pemeriksaan kode keluar itu lebih penting dari yang terlihat. Jika CLI keluar 0 bahkan ketika ada penegasan yang gagal, pipeline Anda akan berwarna hijau pada kode yang rusak, yang lebih buruk daripada tidak memiliki pengujian sama sekali. Paksa kegagalan sekali (rusak penegasan dengan sengaja) dan konfirmasikan Anda mendapatkan kode bukan nol. Kemudian kembalikan penegasan tersebut.

Langkah 3: Buat YAML Azure Pipelines

Tambahkan file bernama azure-pipelines.yml ke root repositori Anda. Titik awal yang lengkap dan berfungsi untuk agen Ubuntu yang di-hosting:

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'

Menjelaskan langkah-langkahnya:

• trigger menjalankan pipeline pada setiap push ke main dan develop. Sesuaikan dengan nama cabang Anda.
• pr menjalankannya pada pull request yang menargetkan main. Ini adalah gerbang yang menghentikan cabang yang rusak agar tidak digabungkan.
• pool / vmImage memilih agen Ubuntu yang dihosting Microsoft. Tidak ada infrastruktur yang perlu dikelola.
• NodeTool@0 menginstal versi Node tertentu, sehingga eksekusi Anda dapat direproduksi.
• Langkah instalasi menarik CLI yang baru pada setiap eksekusi. Untuk build yang lebih cepat, Anda dapat melakukan cache node_modules atau mengunci versi, tetapi mulailah dengan sederhana.
• Langkah eksekusi adalah yang penting. Jika ada penegasan yang gagal, apidog run keluar dengan kode bukan nol, tugas skrip gagal, dan seluruh build menjadi merah.

Referensi $(...) adalah variabel pipeline. SCENARIO_ID, STAGING_ENV_ID, dan terutama APIDOG_ACCESS_TOKEN berasal dari langkah berikutnya, tidak dikodekan secara langsung di sini.

Langkah 4: Simpan rahasia dengan cara yang benar

Token akses Anda tidak boleh berada di YAML dalam bentuk teks biasa. Siapa pun yang memiliki akses baca ke repositori akan melihatnya, dan itu memberikan akses ke proyek Apidog Anda.

Gunakan variabel pipeline rahasia:

1. Di Azure DevOps, buka pipeline Anda dan pilih Edit, lalu Variabel (atau Pustaka untuk grup variabel bersama).
2. Tambahkan APIDOG_ACCESS_TOKEN dan tempel tokennya.
3. Alihkan ikon kunci untuk menandainya sebagai rahasia. Azure mengenkripsinya dan menyembunyikannya di log.

Variabel rahasia tidak disuntikkan ke lingkungan shell secara otomatis; Anda memetakannya secara eksplisit di langkah. Perbarui langkah eksekusi untuk meneruskan rahasia melalui env:

 - 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 dan STAGING_ENV_ID tidak perlu dirahasiakan; perlakukan sebagai variabel biasa untuk keterbacaan, atau pindahkan ke grup variabel yang Anda gunakan kembali di seluruh pipeline. Untuk tim yang mengelola banyak rahasia, dukung grup variabel dengan Azure Key Vault sehingga rotasi terjadi di satu tempat.

Langkah 5: Publikasikan laporan pengujian yang mudah dibaca

Build merah memberi tahu Anda bahwa ada sesuatu yang rusak. Itu tidak memberi tahu Anda apa. Solusinya adalah meminta CLI mengeluarkan laporan dan meminta Azure menampilkannya.

Apidog CLI dapat menulis hasilnya ke file laporan. Arahkan ke format output (HTML untuk manusia, XML gaya JUnit jika Anda ingin tampilan pengujian asli Azure) dan direktori output, lalu publikasikan direktori tersebut.

Untuk artefak yang dapat dibaca manusia:

 - 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'

Dua hal yang perlu diperhatikan. Pertama, condition: always() membuat langkah publikasi berjalan bahkan ketika langkah pengujian gagal; itulah intinya, karena Anda paling menginginkan laporan ketika ada sesuatu yang rusak. Kedua, periksa flag reporter yang tepat (-r, --reporter, atau yang serupa) dan opsi output terhadap apidog run --help untuk versi CLI Anda, lalu sesuaikan contoh agar sesuai.

Jika Anda lebih suka melihat hasil di tab Tes bawaan Azure dengan grafik tren, mintalah CLI mengeluarkan JUnit XML dan tambahkan tugas PublishTestResults@2 yang menunjuk ke XML tersebut. Ini memberi Anda riwayat per-penegasan di seluruh build, bukan hanya satu file.

Langkah 6: Buat gerbang menjadi nyata

Menghubungkan pipeline tidak sama dengan menegakkannya. Secara default, build yang gagal tidak menghentikan siapa pun untuk menggabungkan kecuali Anda memberi tahu Azure DevOps untuk mensyaratkannya.

Atur kebijakan cabang di main:

1. Buka Repos, lalu Branches, temukan main, dan buka Kebijakan cabang.
2. Tambahkan Validasi Build dan pilih pipeline Anda.
3. Tetapkan sebagai wajib.

Sekarang permintaan tarik tidak dapat digabungkan ke main sampai pipeline pengujian API berhasil. Itulah perbedaan antara pengujian yang berjalan dan pengujian yang melindungi. Sampai Anda mengaktifkannya, Anda memiliki dasbor; setelah itu, Anda memiliki gerbang.

Contoh berbasis data yang realistis

Skenario sekali tembak menangkap kerusakan yang jelas. API sungguhan membutuhkan endpoint yang sama yang diuji dengan banyak input; payload yang valid, kasus tepi, permintaan yang salah format yang seharusnya mengembalikan 400 daripada 500.

Apidog mendukung pengujian berbasis data: lampirkan kumpulan data CSV atau JSON ke skenario, dan itu berjalan sekali per baris, mengganti nilai baris ke dalam permintaan dan penegasan. Skenario login, misalnya, mungkin menjalankan baris untuk pengguna yang valid, kata sandi yang salah, akun yang terkunci, dan badan kosong, masing-masing dengan kode status yang diharapkan sendiri.

Dalam pipeline, tidak ada yang berubah tentang bentuk perintah; Anda masih memanggil apidog run terhadap skenario yang sama. Kumpulan data bergerak bersama skenario, jadi satu pemanggilan CLI mencakup setiap baris. Ketika Anda menambahkan kasus tepi baru di Apidog, eksekusi pipeline berikutnya akan mengambilnya tanpa mengedit YAML. Itulah keuntungan menjaga logika pengujian di alat daripada di pipeline: pipeline tetap membosankan sementara cakupan Anda bertambah.

Masalah umum dan cara memperbaikinya

Build berhasil meskipun endpoint rusak. Hampir selalu masalah kode keluar. Konfirmasikan CLI mengembalikan nilai bukan nol saat gagal (Langkah 2), dan pastikan Anda tidak menelannya; || true yang mengikuti atau skrip multi-perintah yang berakhir pada perintah yang berbeda akan menutupi kegagalan. Pertahankan panggilan apidog run sebagai perintah bermakna terakhir dalam blok skripnya.

apidog: perintah tidak ditemukan. Langkah instalasi tidak dijalankan, dijalankan setelah langkah pengujian, atau diinstal ke jalur yang tidak dapat dilihat oleh shell agen. Konfirmasi npm install -g apidog-cli muncul sebelum langkah eksekusi. Pada beberapa agen yang dihosting sendiri, bin npm global tidak ada di PATH; instal secara lokal dan panggil melalui npx apidog run ... sebagai gantinya.

Autentikasi gagal di CI tetapi berfungsi secara lokal. Rahasia tidak mencapai langkah tersebut. Variabel rahasia harus dipetakan melalui env: (Langkah 4); mereka tidak disuntikkan secara otomatis. Periksa juga apakah token belum ditempelkan dengan baris baru atau kutipan yang mengikuti.

Pengujian mengenai lingkungan yang salah. Nilai -e menunjuk ke lingkungan Apidog yang salah, atau URL dasar lingkungan masih mengacu pada localhost. Pertahankan lingkungan Staging khusus yang variabelnya mengarah ke URL yang dapat dijangkau dan aman untuk CI, dan berikan ID-nya secara eksplisit.

Lulus/gagal yang tidak konsisten di setiap eksekusi. Biasanya karena kondisi data bersama yang bisa berubah; sebuah pengujian yang membuat catatan, dan eksekusi selanjutnya yang bertabrakan dengannya. Buat skenario yang mandiri: buat apa yang Anda butuhkan, verifikasi, lalu bersihkan, atau gunakan pengenal unik per eksekusi agar pengulangan tidak terganggu oleh data kemarin. Jika Anda bermigrasi dari alat lain, pola dalam cara menjalankan pengujian API di CI tanpa Newman mencakup jebakan isolasi yang sama.

Di luar dasar-dasar

Setelah pipeline inti kokoh, beberapa ekstensi akan memberikan keuntungan:

• Jadwalkan eksekusi malam hari. Tambahkan pemicu schedules untuk menjalankan seluruh rangkaian pada pukul 2 pagi terhadap staging, sehingga Anda dapat menangkap penyimpangan dari perubahan data atau pergeseran API pihak ketiga bahkan pada hari-hari ketika tidak ada yang melakukan push kode.
• Pisahkan rangkaian cepat dan lambat. Jalankan skenario smoke test cepat di setiap PR untuk umpan balik cepat, dan seluruh rangkaian regresi pada penggabungan ke main. Dua definisi pipeline, CLI yang sama.
• Uji beberapa lingkungan dalam sebuah matriks. Gunakan matriks pipeline untuk menjalankan skenario yang sama terhadap staging dan lingkungan pre-prod secara paralel, masing-masing dengan ID lingkungannya sendiri.
• Amankan penyebaran, bukan hanya penggabungan. Tempatkan tahapan pengujian API sebelum tahapan penyebaran Anda dalam pipeline multi-tahap, sehingga pengujian yang gagal menghentikan rilis, bukan hanya penggabungan.

Masing-masing ini adalah tambahan kecil pada fondasi yang sama: sebuah CLI yang keluar dengan bersih dan sebuah pipeline yang menghormati kode keluar.

Pertanyaan yang Sering Diajukan

Apakah saya perlu menulis kode apa pun untuk menjalankan pengujian API di Azure Pipelines? Tidak. Anda membangun skenario pengujian secara visual di Apidog dan pipeline menjalankannya dengan satu perintah CLI. Satu-satunya "kode" adalah azure-pipelines.yml itu sendiri, yang merupakan konfigurasi, bukan logika pengujian. Jika Anda lebih suka pengujian berbasis skrip sepenuhnya, Anda masih bisa melakukannya, tetapi tujuan dari alur kerja ini adalah untuk melewatkannya.

Bisakah saya menjalankan koleksi Postman yang sudah ada di Azure Pipelines sebagai gantinya? Anda bisa, biasanya dengan Newman atau runner serupa. Jika Anda mempertimbangkan pilihan, Apidog mengimpor koleksi Postman secara langsung, sehingga Anda dapat membawa pengujian yang sudah ada dan menjalankannya melalui CLI yang sama tanpa perlu memelihara toolchain terpisah. Lihat cara menjalankan pengujian API di CI tanpa Newman untuk perbandingannya.

Ke mana pengujian harus diarahkan; staging atau produksi? Staging atau lingkungan pratinjau per cabang, hampir selalu. Menjalankan pengujian yang banyak menulis ke produksi mencemari data nyata dan dapat memicu efek samping nyata. Pertahankan lingkungan Apidog khusus untuk CI dengan URL dasar yang aman, dan berikan ID-nya ke CLI dengan -e.

Bagaimana pipeline tahu bahwa pengujian gagal? Melalui kode keluar. apidog run mengembalikan 0 ketika setiap penegasan berhasil dan kode bukan nol ketika ada yang gagal. Azure Pipelines menggagalkan tugas skrip pada keluar bukan nol, yang menggagalkan build. Verifikasi ini sekali secara lokal dengan echo $? agar Anda percaya pada gerbangnya.

Apakah ini berfungsi dengan pipeline Azure DevOps Classic (UI), bukan hanya YAML? Ya. Langkah-langkah yang sama berlaku; tambahkan tugas "Use Node", tugas command-line yang menjalankan npm install -g apidog-cli, dan tugas command-line lain yang menjalankan apidog run .... YAML direkomendasikan karena berada di repo Anda dan dikendalikan versinya, tetapi runner tidak peduli bagaimana langkah-langkahnya didefinisikan.

Bisakah saya menggunakan agen yang di-host sendiri alih-alih agen yang di-host Microsoft? Ya. Agen yang di-host sendiri bekerja dengan cara yang sama; cukup pastikan Node.js terinstal dan bin npm global ada di PATH agen, atau panggil CLI melalui npx. Agen yang di-host sendiri berguna ketika API staging Anda hanya dapat dijangkau dari dalam jaringan pribadi.

Kesimpulan

Build CI yang hijau seharusnya berarti API Anda benar-benar berfungsi, bukan hanya bahwa kode telah dikompilasi. Untuk mencapainya di Azure Pipelines, ada empat langkah: merancang skenario pengujian nyata di Apidog, menjalankannya secara headless dengan Apidog CLI, membiarkan kode keluar menggerakkan status build, dan mensyaratkan build untuk lulus sebelum ada yang digabungkan. Setelah loop itu berjalan, setiap push mendapatkan pengawasan yang sama seperti yang akan diberikan oleh rekan tim Anda yang paling hati-hati, secara otomatis, setiap saat.

Alasan mengapa ini tetap dapat dipelihara adalah pemisahan. Logika pengujian berada di Apidog, di mana ia dekat dengan spesifikasi API Anda dan mudah diperluas. Pipeline tetap menjadi pembungkus tipis; instal, jalankan, laporkan. Ketika API Anda berkembang, Anda menambahkan skenario dan baris data di alat, dan pipeline terus melakukan pekerjaannya tanpa perlu diedit.

Siap untuk menyiapkannya? Unduh Apidog, buat skenario pengujian, ambil perintah eksekusi CLI, dan masukkan ke dalam azure-pipelines.yml Anda. Regresi berikutnya Anda akan tertangkap oleh mesin, bukan oleh pelanggan.