Strategi deployment dan pengujian aplikasi

Last reviewed 2023-07-20 UTC

Dokumen ini menyediakan ringkasan tentang pola deployment dan pengujian aplikasi yang biasa digunakan. Analisis ini membahas cara kerja pola, manfaat yang ditawarkan dan hal-hal yang perlu dipertimbangkan saat Anda menerapkannya.

Misalnya, Anda ingin mengupgrade aplikasi yang berjalan ke versi baru. Untuk memastikan peluncuran yang lancar, Anda biasanya akan mempertimbangkan hal berikut:

  • Cara meminimalkan periode nonaktif aplikasi, jika ada.
  • Cara mengelola dan mengatasi insiden dengan tanpa menimbulkan dampak yang berarti terhadap pengguna.
  • Cara mengatasi deployment yang gagal dengan cara yang andal dan efektif.
  • Cara meminimalkan jumlah pengguna dan proses yang error untuk mencapai deployment yang dapat diprediksi dan berulang.

Pola deployment yang Anda pilih sangat bergantung pada sasaran bisnis Anda. Misalnya, Anda mungkin perlu meluncurkan perubahan tanpa periode nonaktif, atau meluncurkan perubahan pada lingkungan atau subbagian pengguna sebelum Anda membuat fitur yang tersedia secara umum. Setiap metodologi yang dibahas dalam dokumen ini mempertimbangkan tujuan tertentu yang perlu Anda penuhi sebelum deployment dianggap berhasil.

Dokumen ini ditujukan bagi administrator sistem dan engineer DevOps yang bekerja dalam menentukan dan menerapkan strategi rilis dan deployment untuk berbagai aplikasi, sistem, dan framework

Strategi deployment

Saat Anda deploy layanan, layanan tersebut tidak selalu langsung ditampilkan kepada pengguna. Terkadang, pengguna hanya akan melihat perubahan dalam aplikasi setelah layanan dirilis. Namun, jika layanan siap dirilis, deployment dan rilis terjadi secara bersamaan. Dalam hal ini, saat Anda men-deploy versi baru, versi tersebut mulai menerima traffic produksi. Atau, ada strategi deployment untuk menyediakan beberapa versi layanan secara paralel. Pola deployment ini memungkinkan anda mengontrol dan mengelola versi mana yang menerima permintaan masuk. Baca Kubernetes dan tantangan pengiriman software berkelanjutan untuk mengetahui informasi selengkapnya tentang deployment, rilis, dan konsep terkait.

Pola deployment yang dibahas di bagian ini menawarkan fleksibilitas dalam mengotomatiskan rilis software baru kepada Anda. Pendekatan terbaik bergantung pada tujuan Anda.

Membuat kembali pola deployment

Dengan membuat kembali deployment, Anda dapat sepenuhnya memperkecil versi aplikasi yang ada sebelum meningkatkan skala versi aplikasi baru.

Diagram berikut menunjukkan cara deployment membuat kembali bekerja untuk aplikasi.

Alur dari pembuatan ulang deployment.

Versi 1 mewakili versi aplikasi saat ini, dan Versi 2 mewakili versi aplikasi baru. Saat mengupdate versi aplikasi saat ini, pertama-tama Anda harus menurunkan skala replika yang ada pada Versi 1 hingga nol, kemudian men-deploy replika dengan versi yang baru secara serentak.

Manfaat utama

Manfaat dari pendekatan reka ulang adalah kemudahannya. Anda tidak harus mengelola lebih dari satu versi aplikasi secara paralel, sehingga Anda dapat menghindari tantangan kompatibilitas mundur untuk data dan aplikasi Anda.

Pertimbangan

Metode pembuatan ulang melibatkan periode nonaktif selama proses update. periode nonaktif bukan masalah bagi aplikasi yang dapat menangani masa pemeliharaan atau pemadaman layanan. Namun, jika Anda memiliki aplikasi yang sangat penting dengan perjanjian tingkat layanan (SLA) dan persyaratan ketersediaan tinggi, Anda mungkin akan memilih strategi deployment yang berbeda.

Pola deployment update berkelanjutan

Dalam deployment update berkelanjutan, Anda mengupdate subset dari instance aplikasi yang sedang berjalan bukan mengupdate setiap instance aplikasi secara bersamaan seperti yang ditunjukkan pada diagram berikut.

Alur deployment update berkelanjutan.

Dalam pendekatan deployment ini, jumlah instance yang Anda update secara bersamaan disebut Window Size. Pada diagram sebelumnya, update berkelanjutan memiliki Window Size 1. Satu instance aplikasi diupdate dalam satu waktu. Jika memiliki cluster besar, Anda dapat meningkatkan window size.

Dengan update berkelanjutan, Anda memiliki fleksibilitas terkait cara mengupdate aplikasi:

  • Anda dapat meningkatkan skala instance aplikasi dengan versi baru sebelum memperkecil skala versi lama (proses yang dikenal sebagai upgrade lonjakan).
  • Anda dapat menentukan jumlah maksimum instance aplikasi yang tetap tidak tersedia saat meningkatkan instance baru secara paralel.

Manfaat utama

  • Tanpa periode nonaktif Berdasarkan window size, Anda dapat memperbarui target deployment secara bertahap, misalnya, satu per satu atau dua kali dua. Anda mengarahkan traffic ke target deployment yang diperbarui hanya setelah versi baru aplikasi siap menerima traffic.
  • Mengurangi risiko deployment. Saat Anda meluncurkan update secara bertahap, ketidakstabilan dalam versi baru hanya memengaruhi sebagian pengguna.

Pertimbangan

  • Rollback lambat. Jika peluncuran baru tidak stabil, Anda dapat menghentikan replika baru dan men-deploy ulang versi lama. Namun, seperti proses peluncuran, rollback adalah proses yang bertahap, proses tambahan.
  • Kompatibilitas mundur. Karena kode baru dan kode lama berjalan berdampingan, pengguna mungkin akan diarahkan ke salah satu versi tersebut secara acak. Oleh karena itu, pastikan deployment baru tersebut memiliki kompatibilitas mundur yaitu, versi aplikasi baru dapat membaca dan menangani data yang disimpan oleh versi lama. Data ini dapat mencakup data yang disimpan di disk, database, atau sebagai bagian dari sesi browser pengguna.
  • Sesi memikat. Jika aplikasi memerlukan persistensi sesi, sebaiknya load balancer mendukung kelekatan dan pengosongan koneksi. Selain itu, sebaiknya Anda menjalankan berbagi sesi jika memungkinkan (melalui replikasi sesi atau pengelolaan sesi menggunakan datastore) sehingga sesi dapat dipisahkan dari resource yang mendasarinya.

Pola deployment biru/hijau

Dalam deployment biru/hijau (juga dikenal sebagai deployment merah/hitam), Anda memerintahkan dua deployment identik dari aplikasi Anda, seperti yang ditunjukkan diagram berikut.

Alur deployment biru/hijau.

Dalam diagram, warna biru mewakili versi aplikasi saat ini dan hijau mewakili versi aplikasi baru. Hanya satu versi yang aktif dalam satu waktu. Traffic diarahkan ke blue deployment saat green deployment dibuat dan diuji. Setelah selesai menguji, arahkan traffic ke versi baru.

Setelah deployment berhasil, Anda dapat mempertimbangkan untuk tetap menyimpan blue deployment untuk kemungkinan rollback atau menonaktifkannya. Atau, Anda dapat men-deploy versi aplikasi yang lebih baru pada instance ini. Dalam hal ini, environment (biru) saat ini berfungsi sebagai area staging untuk rilis berikutnya.

Manfaat utama

  • Tanpa periode nonaktif. Blue/green deployment memungkinkan migrasi sistem terjadi dengan cepat tanpa periode nonaktif.
  • Rollback instan. Anda dapat melakukan roll back kapan saja selama proses deployment dengan menyesuaikan load balancer untuk mengarahkan traffic kembali ke environment biru. Dampak periode nonaktif dibatasi pada waktu yang diperlukan untuk mengalihkan traffic ke environment biru setelah masalah terdeteksi.
  • Pemisahan lingkungan. Deployment biru/hijau memastikan bahwa menjalankan environment hijau paralel tidak memengaruhi resource yang mendukung lingkungan biru. Pemisahan ini akan mengurangi risiko deployment Anda.

Pertimbangan

  • Biaya dan overhead operasional. Mengadopsi pola deployment biru/hijau dapat meningkatkan beban dan biaya operasional karena Anda harus mempertahankan lingkungan duplikat dengan infrastruktur yang identik.
  • Kompatibilitas mundur. Deployment biru dan hijau dapat berbagi titik data dan datastore. Sebaiknya Anda memverifikasi bahwa kedua versi aplikasi dapat menggunakan skema datastore dan format data Kompatibilitas mundur ini diperlukan jika Anda ingin beralih dengan lancar di antara kedua versi jika Anda perlu melakukan roll back.
  • Migrasi sistem. Jika Anda berencana menonaktifkan versi saat ini, sebaiknya izinkan pengosongan koneksi yang tepat pada transaksi dan sesi yang ada. Dengan langkah ini, permintaan yang diproses oleh deployment saat ini dapat diselesaikan atau dihentikan dengan baik.

Strategi Pengujian

Pola pengujian yang dibahas di bagian ini biasanya digunakan untuk memvalidasi keandalan dan stabilitas layanan selama tenggang waktu yang wajar berdasarkan tingkat keserentakan dan beban yang realistis.

Pola pengujian Canary

Dalam pengujian canary, Anda meluncurkan sebagian perubahan, lalu mengevaluasi performanya terhadap deployment dasar, seperti yang ditunjukkan diagram berikut.

Konfigurasi untuk pengujian canary.

Dalam pola pengujian ini, deploy versi baru aplikasi bersama dengan versi produksi. Kemudian bagi dan rutekan persentase traffic dari versi produksi ke versi canary dan evaluasi performa canary.

Saat mengonfigurasi canary, pilih metrik utama untuk evaluasi. Sebaiknya bandingkan canary dengan dasar pengukuran yang setara, dan bukan lingkungan produksi langsung.

Untuk mengurangi faktor yang dapat mempengaruhi analisis Anda (seperti caching, koneksi yang aktif dalam waktu lama, dan objek hash), sebaiknya lakukan langkah-langkah berikut untuk versi dasar aplikasi Anda:

  • Pastikan versi dasar pengukuran dan produksi aplikasi Anda sama.
  • Deploy versi dasar pengukuran pada waktu yang sama dengan ketika Anda men-deploy canary.
  • Pastikan deployment dasar pengukuran (seperti jumlah instance aplikasi dan kebijakan penskalaan otomatis) cocok dengan deployment canary.
  • Gunakan versi dasar pengukuran untuk menampilkan traffic yang sama dengan canary.

Dalam pengujian canary, peluncuran sebagian dapat mengikuti berbagai strategi partisi. Misalnya, jika aplikasi memiliki pengguna yang terdistribusi secara geografis, Anda dapat meluncurkan versi baru ke region atau lokasi tertentu terlebih dahulu. Untuk informasi selengkapnya, lihat Mengotomatiskan analisis canary di GKE dengan Spinnaker.

Manfaat utama

  • Kemampuan untuk menguji traffic produksi live. Daripada menguji aplikasi menggunakan simulasi traffic di lingkungan staging, Anda dapat menjalankan pengujian canary pada traffic produksi live. .Dengan peluncuran canary, Anda harus menentukan kelipatan rilis aplikasi baru dan kapan Anda memicu rilis dengan langkah berikutnya. Canary membutuhkan traffic yang cukup sehingga pemantauan dapat mendeteksi masalah dengan jelas
  • Rollback cepat. Anda dapat melakukan roll back secara cepat dengan mengalihkan traffic pengguna ke aplikasi versi lama.
  • Tanpa periode nonaktif. Perilisan Canary memungkinkan Anda merutekan traffic produksi live ke berbagai versi aplikasi tanpa periode nonaktif.

Pertimbangan

  • Peluncuran lambat. Setiap rilis inkremental memerlukan pemantauan selama periode yang wajar dan, akibatnya, dapat menunda rilis secara keseluruhan. Pengujian canary sering kali memerlukan waktu beberapa jam.
  • Kemampuan observasi. Prasyarat untuk menerapkan pengujian canary adalah kemampuan mengamati dan memantau infrastruktur dan stack aplikasi Anda secara efektif. Menerapkan pemantauan yang andal dapat memerlukan upaya yang signifikan.
  • Kompatibilitas mundur dan sesi memikat. Seperti update berkelanjutan, pengujian canary dapat menimbulkan risiko dengan inkompatibilitas mundur dan persistensi sesi karena beberapa versi aplikasi berjalan di lingkungan selama canary di-deploy.

Pola pengujian A/B

Dengan pengujian A/B, Anda menguji hipotesis menggunakan implementasi varian. Pengujian A/B digunakan untuk membuat keputusan bisnis (bukan hanya prediksi) tapi berdasarkan hasil data.

Saat melakukan pengujian A/B, Anda merutekan subset pengguna ke fungsi baru berdasarkan aturan pemilihan rute, seperti yang ditunjukkan pada diagram berikut.

Konfigurasi untuk pengujian A/B.

Aturan pemilihan rute sering kali mencakup faktor seperti versi browser, agen pengguna, geolokasi, dan sistem operasi. Setelah mengukur dan membandingkan versi, Anda akan memperbarui lingkungan produksi dengan versi yang memberikan hasil yang lebih baik.

Manfaat utama

Pengujian A/B paling cocok digunakan untuk mengukur efektivitas fungsi pada suatu aplikasi. Kasus penggunaan pola deployment yang dibahas sebelumnya berfokus pada perilisan software baru dengan aman dan roll back yang dapat diprediksi. Dalam pengujian A/B, kontrol target audiens Anda untuk fitur baru dan pantau setiap perbedaan yang signifikan secara statistik dalam perilaku pengguna.

Pertimbangan

  • Penyiapan yang kompleks. Pengujian A/B memerlukan contoh representatif yang dapat digunakan untuk menampilkan bukti bahwa suatu versi lebih baik daripada versi lainnya. Anda perlu menghitung ukuran sampel terlebih dahulu (misalnya, dengan menggunakan Kalkulator ukuran sampel pengujian A/B ) dan jalankan pengujian selama periode yang wajar untuk mencapai data statistik yang signifikan setidaknya 95%.
  • Keabsahan hasil. Beberapa faktor dapat mempengaruhi hasil pengujian, termasuk positif palsu (PP), sampel bias, atau faktor eksternal (seperti tren musiman atau promosi pemasaran).
  • Kemampuan observasi. Saat Anda menjalankan beberapa pengujian A/B pada traffic yang tumpang-tindih, proses pemantauan dan pemecahan masalah bisa menjadi sulit. Misalnya, jika Anda menguji halaman produk A versus halaman produk B, atau halaman checkout C versus halaman checkout D, pelacakan terdistribusi menjadi penting untuk menentukan metrik seperti pemisahan traffic antarversi.

Pola uji bayangan

Teknik eksperimen berurutan seperti uji canary dapat berpotensi mengekspos pelanggan ke versi aplikasi yang lebih rendah selama tahap awal pengujian. Anda dapat mengelola risiko ini dengan menggunakan teknik offline seperti simulasi. Namun, teknik offline tidak memvalidasi peningkatan aplikasi karena tidak ada interaksi antara pengguna dengan versi baru.

Dengan pengujian bayangan, Anda men-deploy dan menjalankan versi baru bersama versi saat ini, namun dengan cara membuat versi baru tersebut tersembunyi dari pengguna, seperti yang ditunjukkan diagram berikut.

Konfigurasi untuk uji bayangan.

Permintaan yang masuk akan dicerminkan dan di-replay di lingkungan pengujian. Proses ini dapat terjadi baik secara real time atau asinkron setelah salinan dari traffic produksi gambar yang direkam sebelumnya di-replay terhadap layanan yang baru di-deploy.

Anda harus memastikan bahwa pengujian bayangan tidak memicu efek samping yang dapat mengubah lingkungan produksi yang ada atau status pengguna.

Manfaat utama

  • Tidak ada dampak produksi. Karena traffic diduplikasi, segala bug dalam layanan yang memproses data bayangan tidak akan berdampak pada produksi.
  • Menguji fitur baru backend menggunakan beban produksi. Saat digunakan bersama alat seperti Diffy, bayangan traffic memungkinkan Anda mengukur perilaku layanan Anda terhadap traffic produksi live. Dengan kemampuan ini, memungkinkan Anda menguji error, pengecualian, performa, dan paritas hasil antara versi aplikasi.
  • Mengurangi risiko deployment. Traffic tumpang tindih biasanya digabungkan dengan pendekatan lain seperti pengujian canary. Setelah menguji fitur baru dengan menggunakan traffic tumpang tindih, selanjutnya Anda akan menguji pengalaman pengguna dengan merilis fitur tersebut secara bertahap ke jumlah pengguna yang meningkat seiring waktu. Peluncuran penuh tidak akan terjadi hingga aplikasi memenuhi persyaratan stabilitas dan performa

Pertimbangan

  • Efek samping. Dengan traffic tumpang tindih, Anda harus berhati-hati dalam menangani layanan yang mengubah status atau berinteraksi dengan layanan pihak ketiga. Misalnya, jika Anda ingin menguji bayangan pada layanan pembayaran untuk platform keranjang belanja, pelanggan dapat membayar dua kali untuk pesanan mereka. Untuk menghindari pengujian bayangan yang mungkin menghasilkan mutasi yang tidak diinginkan atau interaksi berisiko lainnya, sebaiknya gunakan stub atau alat virtualisasi lainnya seperti Hoverfly bukan sistem atau datastore pihak ketiga.
  • Biaya dan overhead operasional. Pengujian bayangan cukup kompleks untuk disiapkan. Selain itu, seperti deployment biru/hijau, deployment bayangan memiliki konsekuensi biaya dan implikasi operasional karena penyiapan membutuhkan pengoperasian dan dan pengelolaan dua lingkungan secara paralel.

Memilih strategi yang tepat

Anda dapat men-deploy dan merilis aplikasi melalui beberapa cara. Setiap pendekatan memiliki kelebihan dan kekurangan. Pilihan terbaik adalah berdasarkan kebutuhan dan kendala bisnis Anda. Pertimbangkan hal berikut:

  • Apa pertimbangan Anda yang paling penting? Misalnya, apakah periode nonaktif dapat diterima? Apakah biaya membatasi Anda? Apakah tim Anda memiliki keterampilan yang tepat untuk melakukan penyiapan peluncuran dan rollback yang kompleks?
  • Apakah Anda telah menerapkan kontrol pengujian yang ketat, atau ingin menguji rilis baru terhadap traffic produksi untuk memastikan stabilitas rilis dan membatasi dampak negatif?
  • Apakah Anda ingin menguji fitur di antara kumpulan pengguna untuk memverifikasi hipotesis bisnis tertentu? Dapatkah Anda mengontrol apakah pengguna yang ditargetkan menerima update? Misalnya, update di perangkat seluler memerlukan tindakan eksplisit dari pengguna dan mungkin memerlukan izin tambahan.
  • Apakah microservice di lingkungan Anda sepenuhnya bersifat otonom? Atau, apakah Anda memiliki aplikasi campuran bergaya microservice yang dapat bekerja bersama aplikasi tradisional, yang sulit diubah? Untuk informasi selengkapnya, lihat pola deployment pada lingkungan hybrid dan multi-cloud.
  • Apakah rilis baru melibatkan perubahan skema? Jika ya, apakah skema berubah terlalu kompleks untuk dipisahkan dari perubahan kode?

Tabel berikut merangkum karakteristik penting dari pola deployment dan pengujian yang dibahas sebelumnya dalam dokumen ini. Ketika Anda mempertimbangkan kelebihan dan kekurangan dari berbagai pendekatan deployment dan pengujian, pertimbangkan kebutuhan bisnis dan resource teknologi Anda, lalu pilih opsi yang paling menguntungkan Anda.

Pola deployment atau
pengujian		 Tanpa Periode Nonaktif Pengujian traffic produksi nyata Melepaskan akses kepada pengguna berdasarkan kondisi Durasi rollback Dampak pada biaya hardware dan cloud
Buat ulang
Versi 1 dihentikan, dan Versi 2 diluncurkan.		 x x x Cepat, tetapi disruptif karena periode nonaktif Tidak perlu penyiapan tambahan
Update berkelanjutan
Versi 2 diluncurkan secara bertahap dan menggantikan Versi 1.		 ✓ x x Lambat Dapat memerlukan penyiapan tambahan untuk upgrade lonjakan
Biru/hijau
Versi 2 dirilis bersama Versi 1; traffic dialihkan ke Versi 2 setelah diuji.		 ✓ x x Instan Perlu mempertahankan lingkungan biru dan hijau secara bersamaan
Canary
Versi 2 dirilis ke sebagian pengguna, diikuti dengan peluncuran penuh.		 ✓ ✓ x Cepat Tidak perlu penyiapan tambahan
A/B
Versi 2 dirilis, dalam kondisi tertentu, untuk sebagian pengguna.		 ✓ ✓ ✓ Cepat Tidak perlu penyiapan tambahan
Bayangan
Versi 2 menerima traffic dunia nyata tanpa mempengaruhi permintaan pengguna.		 ✓ ✓ x Tidak berlaku. Perlu mempertahankan lingkungan paralel untuk mengambil dan memutar ulang permintaan pengguna

Praktik terbaik

Untuk meminimalkan risiko deployment dan pengujian, tim aplikasi dapat mengikuti beberapa praktik terbaik:

  • Kompatibilitas mundur. Saat Anda menjalankan beberapa versi aplikasi secara bersamaan, pastikan database tersebut kompatibel dengan semua versi aktif. Misalnya, rilis baru memerlukan perubahan skema ke database (seperti kolom baru). Dalam skenario seperti itu, Anda perlu mengubah skema database agar kompatibel dengan versi lama. Setelah menyelesaikan peluncuran penuh, Anda dapat menghapus dukungan untuk skema lama, sehingga hanya menyisakan dukungan untuk versi terbaru. Salah satu cara untuk mencapai kompatibilitas mundur adalah dengan memisahkan perubahan skema dari perubahan kode. Untuk informasi selengkapnya, lihat pola perubahan paralel dan pemfaktoran ulang database.
  • Continuous integration/continuous deployment (CI/CD). CI memastikan bahwa kode yang diperiksa ke cabang fitur akan bergabung dengan cabang utamanya saja setelah berhasil lulus pemeriksaan dependensi, pengujian unit dan integrasi, dan proses build. Oleh karena itu, setiap perubahan pada aplikasi diuji sebelum dapat di-deploy. Dengan CD, artefak kode yang di-build CI dikemas dan siap di-deploy di satu atau beberapa lingkungan. Untuk informasi selengkapnya, lihat mem-build pipeline CI/CD dengan Google Cloud.
  • Automation. Jika Anda mengirimkan update aplikasi secara terus menerus kepada pengguna, sebaiknya build proses otomatis yang dapat mem-build, menguji, dan men-deploy software dengan andal. Sebaiknya perubahan kode Anda mengalir secara otomatis melalui pipeline CI/CD yang mencakup pembuatan artefak, pengujian unit, pengujian fungsi, dan peluncuran produksi. Dengan menggunakan alat otomatisasi seperti Cloud Build, Cloud Deploy, Spinnaker, dan Jenkins, Anda dapat mengotomatiskan proses deployment agar lebih efisien, andal, dan dapat diprediksi.
  • IaC dan GitOps. Jika Anda perlu mengelola strategi deployment dan pengujian yang rumit, yang rumit, pertimbangkan untuk menggunakan alat infrastruktur as Code (IaC) dan GitOps. Penggunaan IaC dengan Terraform dan Config Connector dapat membantu Anda menggunakan bahasa yang deklaratif untuk menentukan infrastruktur dan strategi Anda. Penggunaan GitOps dengan Config Sync, and Argo CD. dapat membantu Anda mengelola kode dengan git.
  • Strategi rollback. Terkadang, terjadi kesalahan. Sebaiknya membuat strategi rollback untuk mengikuti saat terjadi hal-hal yang tidak terduga. Memiliki strategi rollback yang andal dapat membantu administrator dan engineer DevOps mengelola risiko. Anda dapat membuat strategi rollback menggunakan platform yang mendukung rollback sebagai fitur bawaan, seperti App Engine, dan Cloud Run. Untuk mendukung kebutuhan rollback, Anda juga dapat menggunakan alat otomatisasi rilis seperti Cloud Deploy, Spinnaker, dan Argo RollOuts.
  • Pemantauan pasca-deployment. Untuk memantau metrik penting dan memberi tahu tim yang bertanggung jawab saat deployment atau pengujian gagal, bangun sistem pemantauan menggunakan Kemampuan Observasi Google Cloud. Anda juga dapat mengaktifkan rollback otomatis untuk deployment yang gagal health check. Menggunakan Error Reporting, Cloud Trace dan Cloud Profiler dapat membantu Anda menemukan penyebab masalah pasca-deployment yang sederhana dan kompleks.

Langkah selanjutnya