Siklus proses pengembangan API

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Setiap organisasi memiliki software development lifecycle (SDLC) yang unik. Anda sering kali perlu menyinkronkan dan menyelaraskan deployment proxy API dengan proses yang sama yang Anda gunakan saat ini untuk mengembangkan, menguji, dan men-deploy aplikasi lain.

Layanan API menyediakan alat dan API RESTful yang memungkinkan Anda mengintegrasikan deployment dan pengelolaan proxy API ke dalam SDLC organisasi Anda. Penggunaan umum RESTful API adalah untuk menulis skrip atau kode yang men-deploy proxy API secara terprogram, atau memigrasikan proxy API dari satu lingkungan ke lingkungan lain, sebagai bagian dari proses otomatis yang lebih besar yang juga men-deploy atau memigrasikan aplikasi lain. Layanan API tidak membuat asumsi tentang SDLC Anda (atau orang lain, dalam hal ini). Sebaliknya, versi ini mengekspos fungsi atomik yang dapat dikoordinasikan oleh tim pengembangan untuk mengotomatiskan dan mengoptimalkan siklus proses pengembangan API Anda.

API Services API didokumentasikan dalam Referensi API. Lihat referensi API untuk memulai.

Lingkungan

Setiap organisasi di Apigee Edge memiliki setidaknya dua lingkungan deployment yang tersedia untuk proxy API: 'test' dan 'prod'. Perbedaan antara kedua lingkungan tersebut bersifat tidak tentu — setiap lingkungan hanya diidentifikasi oleh kumpulan alamat jaringan (URL) yang berbeda. Tujuannya adalah untuk memberi Anda domain tempat Anda dapat membangun dan memverifikasi proxy API sebelum API diekspos ke developer eksternal.

Anda dapat memanfaatkan lingkungan ini untuk menyinkronkan pengembangan proxy API yang diproses dengan SDLC. Setiap lingkungan ditentukan oleh alamat jaringan, sehingga Anda dapat memisahkan traffic antara proxy API yang sedang Anda kerjakan, dan proxy yang sedang diakses oleh aplikasi saat runtime. Alamat jaringan yang tersedia untuk setiap lingkungan ditentukan dalam kumpulan Host Virtual yang tersedia di lingkungan tersebut.

Masuk, TLS/SSL server diaktifkan secara otomatis untuk setiap lingkungan. Dua VirtualHost telah ditentukan sebelumnya di setiap lingkungan: default dan secure. Default menentukan alamat HTTP, sedangkan Secure menentukan alamat HTTP/S, dengan TLS/SSL sisi server yang telah dikonfigurasi sebelumnya. Dalam konfigurasi proxy API, Anda menunjukkan VirtualHost yang harus diproses oleh ProxyEndpoint. Saat mempromosikan ke produksi, Anda biasanya menonaktifkan HTTP dengan menghapus VirtualHost default dari konfigurasi proxy API.

Misalnya, ProxyEndpoint berikut memproses di HTTP dan HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Dengan menghapus VirtualHost default dari konfigurasi ProxyEndpoint, Anda membuat proxy API yang hanya memantau di HTTPS, bukan di HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Anda dapat melihat VirtualHost yang tersedia di lingkungan dengan memilih Environments di menu utama UI pengelolaan.

Lingkungan juga menyediakan pemisahan data dan resource. Misalnya, Anda dapat menyiapkan cache yang berbeda saat pengujian dan produksi, yang hanya dapat diakses oleh proxy API yang dijalankan di lingkungan tersebut. Selain itu, kunci API yang dikeluarkan di lingkungan pengujian tidak valid di lingkungan produksi, begitu pula sebaliknya.

Men-deploy proxy API ke lingkungan

Saat membuat proxy API, Anda harus memutuskan lingkungan mana yang akan Anda gunakan. Anda dapat memilih untuk membuat proxy API baru pada produksi, tetapi hal ini tidak direkomendasikan karena Anda dapat mengekspos API kepada developer sebelum siap. Secara umum, mulailah dengan membuat proxy API di test yang, setelah pengujian, Anda kemudian akan mempromosikan ke prod.

Untuk informasi selengkapnya, lihat Memahami deployment.

Pengembangan iteratif dalam pengujian

Saat Anda mengerjakan proxy API, Layanan API menyimpan iterasi konfigurasi Anda sebagai revisi. Saat men-deploy proxy API, Anda memilih revisi tertentu yang akan di-deploy. Biasanya, Anda men-deploy revisi terbaru, dan, jika perlu, mengembalikan ke nomor revisi sebelumnya. Anda dapat memilih tempat untuk men-deploy revisi tersebut. Misalnya, Anda dapat mempromosikan revisi ke produksi untuk memungkinkan developer mulai menggunakan API Anda. Secara bersamaan, Anda mungkin akan melakukan iterasi beberapa revisi saat dalam pengujian, dengan menambahkan fitur atau meningkatkan kebijakan. Kemudian, jika sudah siap, Anda dapat men-deploy revisi baru ke produksi, yang menimpa revisi yang ada di lingkungan tersebut. Dengan metode ini, Anda dapat memiliki revisi langsung API kapan saja dan tersedia bagi developer saat Anda melakukan pengembangan.

Promosi ke produksi

Jika proxy API telah diterapkan dan diuji sepenuhnya, proxy API siap dipromosikan ke 'prod'. Revisi proxy API dalam pengujian akan digunakan untuk menimpa revisi proxy API yang di-deploy di produksi.

Layanan API memberikan kemampuan untuk memastikan deployment proxy API yang lancar, sehingga meminimalkan dampak pada aplikasi dan pengguna akhir selama prosedur deployment.

Deployment skrip

UI pengelolaan Apigee Edge memungkinkan Anda men-deploy proxy API ke produksi langsung dari builder proxy API. Namun, dalam banyak situasi, persyaratan keamanan, keandalan, dan konsistensi akan mewajibkan tim pengembangan membuat skrip prosedur deployment. Untuk melakukannya, Anda dapat menulis kode dan skrip yang memanggil RESTful API yang diekspos oleh Layanan API.

Referensi lingkungan

Untuk kontrol tambahan selama promosi, sebaiknya Anda hanya melakukan iterasi pada proxy API dalam pengujian, dan membuat perubahan sesedikit mungkin yang diperlukan pada proxy API yang di-deploy dalam produksi.

Untuk melakukannya, Anda harus memastikan bahwa resource tertentu yang terkait dengan setiap lingkungan telah dikonfigurasi sedemikian rupa sehingga dapat tetap statis dalam konfigurasi proxy API.

• URL Target: Sudah umum bagi proxy API untuk memanggil URL backend yang berbeda selama pengujian dan produksi. Anda dapat menggunakan konfigurasi TargetServer untuk membuat konfigurasi TargetEndpoint yang tidak bergantung pada lingkungan. Lihat Load balancing di beberapa server backend.
• Cache dan Peta kunci/nilai: Kedua resource persistensi dicakup oleh lingkungan. Anda harus memastikan bahwa konvensi penamaan digunakan untuk mengaktifkan proxy API untuk menyimpan data tanpa memerlukan perubahan konfigurasi selama promosi. Lihat Membuat dan mengedit cache lingkungan.
• Target ServiceCallout: Pemanggilan layanan dapat menggunakan target yang berbeda bergantung pada lingkungannya, jika, misalnya, ServiceCallout di lingkungan pengujian menggunakan layanan demo. Lihat kebijakan Panggilan Layanan.

Untuk membuat konfigurasi proxy API tidak bergantung pada lingkungan, Anda juga dapat menggunakan pernyataan kondisional. Pernyataan bersyarat yang dibuat dengan variabel environment.name dapat digunakan untuk mengevaluasi lingkungan saat ini sebelum menerapkan kebijakan atau sebelum merutekan ke URL pada backend.

Untuk informasi selengkapnya, lihat Memahami deployment.