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 Anda perlu menyinkronkan dan menyelaraskan deployment proxy API dengan proses yang sama seperti 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 untuk 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 lainnya. Layanan API tidak membuat asumsi tentang SDLC Anda (atau orang lain, dalam hal ini). Sebaliknya, API ini mengekspos fungsi atom yang dapat dikoordinasikan oleh tim pengembangan Anda untuk mengotomatiskan dan mengoptimalkan siklus proses pengembangan API.

API Layanan 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 arbitrer — 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 Anda. Setiap lingkungan ditentukan oleh alamat jaringan, yang memungkinkan Anda memisahkan traffic antara proxy API yang sedang Anda kerjakan, dan yang diakses oleh aplikasi saat runtime. Alamat jaringan yang tersedia untuk setiap lingkungan ditentukan dalam kumpulan VirtualHost yang tersedia di lingkungan tersebut.

Masuk, TLS/SSL server otomatis diaktifkan untuk setiap lingkungan. Dua VirtualHost telah ditentukan sebelumnya di setiap lingkungan: default dan secure. Default menentukan alamat HTTP, sementara Secure menentukan alamat HTTP/S, dengan TLS/SSL sisi server yang telah dikonfigurasi sebelumnya. Dalam konfigurasi proxy API, Anda menunjukkan VirtualHost mana 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 HTTP dan HTTPS.

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

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

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

Anda dapat melihat VirtualHost mana 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 di pengujian dan produksi, yang hanya dapat diakses oleh proxy API yang dijalankan di lingkungan tersebut. Selain itu, kunci API yang diterbitkan di lingkungan pengujian tidak valid di lingkungan produksi, dan sebaliknya.

Men-deploy proxy API ke lingkungan

Saat membuat proxy API, Anda harus memutuskan lingkungan tempat Anda akan bekerja. 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, mulai dengan membuat proxy API di test yang, setelah pengujian, Anda kemudian mempromosikan ke prod.

Untuk mengetahui informasi selengkapnya, lihat Memahami deployment.

Pengembangan iteratif dalam pengujian

Saat Anda mengerjakan proxy API, Layanan API akan 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 iterasi beberapa revisi pada pengujian, tempat Anda menambahkan fitur atau menyesuaikan kebijakan. Kemudian, jika sudah siap, Anda dapat men-deploy revisi baru ke produksi, yang akan menimpa revisi yang ada di lingkungan tersebut. Dengan menggunakan metode ini, Anda dapat selalu menyediakan revisi API secara langsung kepada developer saat Anda mengembangkannya.

Promosi ke produksi

Setelah diimplementasikan 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 produk.

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

Deployment pembuatan skrip

UI pengelolaan Apigee Edge memungkinkan Anda men-deploy proxy API ke produksi langsung dari pembuat 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 ditampilkan oleh Layanan API.

Resource lingkungan

Untuk kontrol tambahan selama promosi, sebaiknya Anda hanya melakukan iterasi pada proxy API yang sedang diuji, dan membuat perubahan sesedikit mungkin pada proxy API yang di-deploy dalam 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 tidak bergantung pada lingkungan. Lihat Load balancing di beberapa server backend.
• Cache dan Peta nilai kunci: Kedua resource persistensi dicakup oleh 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: Info layanan dapat menggunakan target yang berbeda bergantung pada lingkungan, misalnya, jika ServiceCallout di lingkungan pengujian menggunakan layanan demo. Lihat kebijakan Info Layanan.

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

Untuk informasi selengkapnya, lihat Memahami deployment.