Siklus proses pengembangan API

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

Setiap organisasi memiliki siklus proses pengembangan software (SDLC) yang unik. Sering kali diperlukan untuk menyinkronkan dan menyelaraskan penerapan proxy API dengan proses yang sama seperti yang Anda gunakan saat ini mengembangkan, menguji, dan men-deploy aplikasi lainnya.

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

API Layanan API didokumentasikan dalam Referensi API. Lihat Referensi API yang mendapatkan memulai.

Tonton video ini untuk pengantar lingkungan API dan pengembangan API siklus proses.

Lingkungan

Setiap organisasi di Apigee Edge memiliki setidaknya dua lingkungan deployment yang tersedia untuk proxy API: 'test' dan 'prod'. Perbedaan antara kedua lingkungan ini bersifat arbitrer — setiap lingkungan hanya diidentifikasi dengan kumpulan alamat jaringan (URL) yang berbeda. Tujuan tujuannya adalah menyediakan domain tempat Anda dapat membangun dan memverifikasi proxy API sebelum API digunakan oleh developer eksternal.

Anda bisa memanfaatkan lingkungan ini untuk menyinkronkan pengembangan proxy API yang diproses dengan SDLC. Setiap lingkungan ditentukan oleh alamat jaringan, yang memungkinkan Anda memisahkan traffic di antara proxy API yang sedang Anda kerjakan, dan yang sedang diakses oleh aplikasi saat runtime. Alamat jaringan yang tersedia untuk setiap lingkungan ditentukan dalam kumpulan {i>VirtualHost<i} yang tersedia di lingkungan tersebut.

TLS/SSL masuk server akan otomatis diaktifkan untuk setiap lingkungan. Dua VirtualHost adalah telah ditentukan sebelumnya di setiap lingkungan: default dan secure. Default mendefinisikan Alamat HTTP, meskipun Secure menentukan alamat HTTP/S, dengan TLS/SSL sisi server yang telah dikonfigurasi sebelumnya. Di beberapa konfigurasi proxy API, Anda menunjukkan {i>VirtualHost<i} mana yang harus dipantau oleh ProxyEndpoint. Saat mempromosikan ke produk, Anda biasanya menonaktifkan HTTP dengan menghapus default VirtualHost dari konfigurasi proxy API.

Misalnya, ProxyEndpoint berikut memproses 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 dan bukan di HTTP.

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

Anda dapat melihat {i>VirtualHost<i} mana yang tersedia di suatu lingkungan dengan memilih Lingkungan di menu utama UI pengelolaan.

Lingkungan juga menyediakan pemisahan data dan resource. Misalnya, Anda dapat menyiapkan cache berbeda dalam pengujian dan produksi, yang hanya dapat diakses oleh proxy API yang mengeksekusi lingkungan fleksibel App Engine. Selain itu, kunci API yang dikeluarkan di lingkungan pengujian tidak valid dalam prod, dan sebaliknya.

Men-deploy proxy API ke lingkungan

Saat membuat proxy API, Anda harus memutuskan lingkungan tempat Anda akan bekerja. Anda dapat memilih membuat proxy API baru pada produksi, tetapi hal itu tidak disarankan karena Anda dapat API kepada pengembang sebelum ia siap. Secara umum, mulailah dengan membuat proxy API di test yang, setelah pengujian, Anda kemudian mempromosikan ke prod.

Untuk informasi selengkapnya, lihat Memahami deployment.

Pengembangan iteratif dalam pengujian

Saat Anda mengerjakan proxy API, Layanan API akan menyimpan iterasi konfigurasi sebagai revisi Google Cloud. Saat men-deploy proxy API, Anda memilih revisi tertentu untuk di-deploy. Biasanya, Anda men-deploy revisi terbaru, dan, jika perlu, mengembalikan ke versi sebelumnya nomor revisi. Anda dapat memilih tempat untuk men-deploy revisi tersebut. Misalnya, Anda dapat mempromosikan revisi ke produksi untuk memungkinkan pengembang mulai bekerja dengan API Anda. Pada saat yang sama, Anda mungkin melakukan iterasi beberapa revisi pada pengujian, dengan menambahkan fitur atau kebijakan fine-tuning. Lalu: jika Anda siap, Anda dapat men-deploy revisi baru ke prod, menimpa revisi yang ada pada lingkungan tersebut. Dengan menggunakan metode ini, Anda selalu dapat memiliki revisi langsung atas API Anda yang tersedia developer saat Anda mengembangkan aplikasi.

Promosi ke prod

Bila proxy API telah diimplementasikan dan diuji sepenuhnya, proxy tersebut siap untuk dipromosikan menjadi 'prod'. Revisi proxy API yang diuji akan digunakan untuk menimpa revisi proxy API yang di-deploy pada produksi.

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

Deployment skrip

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

Resource lingkungan

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

Untuk melakukannya, Anda perlu memastikan bahwa sumber daya tertentu yang terkait dengan setiap lingkungan telah dikonfigurasi sedemikian rupa sehingga bisa tetap statis dalam konfigurasi proxy API.

  • URL Target: Proxy API biasanya memanggil URL backend yang berbeda selama pengujian dan produksi. Anda dapat menggunakan konfigurasi TargetServer untuk membuat konfigurasi yang tidak bergantung pada lingkungan Konfigurasi TargetEndpoint. Lihat Load balancing di seluruh server backend.
  • Peta Cache dan Kunci/nilai: Kedua resource persistensi dibatasi oleh lingkungan. Anda seharusnya memastikan bahwa konvensi penamaan digunakan untuk memungkinkan proxy API menyimpan data tanpa perubahan konfigurasi selama promosi. Lihat Membuat dan mengedit cache lingkungan.
  • Target ServiceInfo: Info layanan dapat menggunakan target yang berbeda bergantung pada jika, misalnya, ServiceInfo di lingkungan pengujian menggunakan layanan demo. Lihat kebijakan Pemanggilan Layanan.

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

Untuk informasi selengkapnya, lihat Memahami deployment.