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 sinkronisasi dan penyelarasan 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 RESTful API yang memungkinkan Anda mengintegrasikan deployment dan pengelolaan proxy API ke dalam SDLC organisasi Anda. Penggunaan umum RESTful API adalah menulis skrip atau kode yang men-deploy proxy API secara terprogram, atau yang 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 SDLC orang lain). Sebaliknya, API ini 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 Mulai menggunakan referensi API.

Lingkungan

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

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

TLS/SSL server masuk 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 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 default VirtualHost dari konfigurasi ProxyEndpoint, Anda membuat proxy API yang hanya memproses HTTPS, bukan 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 dalam 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 prod, dan sebaliknya.

Men-deploy proxy API ke lingkungan

Saat membuat proxy API, Anda harus memutuskan lingkungan yang akan digunakan. Anda dapat memilih untuk membuat proxy API baru di 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, akan Anda promosikan ke prod.

Untuk mengetahui 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 untuk 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 agar developer dapat mulai menggunakan API Anda. Pada saat yang sama, Anda mungkin melakukan beberapa revisi pada pengujian, tempat Anda menambahkan fitur atau menyesuaikan kebijakan. Kemudian, jika sudah siap, Anda dapat men-deploy revisi baru ke produksi, menggantikan revisi yang ada di lingkungan tersebut. Dengan menggunakan metode ini, Anda selalu dapat menyediakan revisi aktif API untuk developer saat Anda melakukan pengembangan.

Promosi ke produksi

Setelah diimplementasikan dan diuji sepenuhnya, proxy API siap dipromosikan ke 'prod'. Revisi proxy API dalam pengujian akan digunakan untuk menggantikan revisi proxy API yang di-deploy di prod.

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

Men-deploy skrip

UI pengelolaan Apigee Edge memungkinkan Anda men-deploy proxy API ke produksi langsung dari pembuat proxy API. Namun, dalam banyak situasi, persyaratan untuk 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 melakukan perubahan sesedikit mungkin pada proxy API yang di-deploy di produksi.

Untuk melakukannya, Anda harus memastikan bahwa resource tertentu yang terkait dengan setiap lingkungan dikonfigurasi sedemikian rupa sehingga dapat 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 TargetEndpoint yang independen terhadap lingkungan. Lihat Load balancing di seluruh server backend.
• Cache dan Peta nilai kunci: Kedua resource persistensi dicakup berdasarkan lingkungan. Anda harus memastikan bahwa konvensi penamaan digunakan untuk memungkinkan proxy API menyimpan data tanpa memerlukan perubahan konfigurasi selama promosi. Lihat Membuat dan mengedit cache lingkungan.
• Target ServiceCallout: Service callout dapat menggunakan target yang berbeda, bergantung pada lingkungan, misalnya, jika ServiceCallout di lingkungan pengujian menggunakan layanan demo. Lihat kebijakan Service Callout.

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

Untuk mengetahui informasi selengkapnya, lihat Memahami deployment.