Penyebaran dan pengujian untuk beban kerja misi penting di Azure

Penyebaran yang gagal dan rilis yang salah adalah penyebab umum untuk pemadaman aplikasi. Pendekatan Anda untuk penyebaran dan pengujian memainkan peran penting dalam keandalan keseluruhan aplikasi misi penting.

Penyebaran dan pengujian harus membentuk dasar untuk semua operasi aplikasi dan infrastruktur untuk memastikan hasil yang konsisten untuk beban kerja misi penting. Bersiaplah untuk menyebarkan mingguan, harian, atau lebih sering. Rancang alur integrasi berkelanjutan dan penyebaran berkelanjutan (CI/CD) Anda untuk mendukung tujuan tersebut.

Strategi harus menerapkan:

• Pengujian pra-rilis yang ketat. Updates tidak boleh menimbulkan cacat, kerentanan, atau faktor lain yang mungkin membahgi kesehatan aplikasi.

• Penyebaran transparan. Dimungkinkan untuk meluncurkan pembaruan kapan saja tanpa memengaruhi pengguna. Pengguna harus dapat melanjutkan interaksi mereka dengan aplikasi tanpa gangguan.

• Operasi yang sangat tersedia. Proses dan alat penyebaran dan pengujian harus sangat tersedia untuk mendukung keandalan aplikasi secara keseluruhan.

• Proses penyebaran yang konsisten. Artefak dan proses aplikasi yang sama harus digunakan untuk menyebarkan infrastruktur dan kode aplikasi di berbagai lingkungan. Otomatisasi end-to-end adalah wajib. Intervensi manual harus dihindari karena dapat menimbulkan risiko keandalan.

Area desain ini memberikan rekomendasi tentang cara mengoptimalkan proses penyebaran dan pengujian dengan tujuan meminimalkan waktu henti dan menjaga kesehatan dan ketersediaan aplikasi.

Penting

Artikel ini adalah bagian dari seri beban kerja misi penting Azure Well-Architected Framework . Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan Apa itu beban kerja misi penting?.

Penyebaran waktu henti nol

Lihat video berikut untuk ringkasan penyebaran waktu henti nol.

Mencapai penyebaran waktu henti nol adalah tujuan mendasar untuk aplikasi yang sangat penting. Aplikasi Anda harus tersedia sepanjang hari, setiap hari, bahkan ketika rilis baru diluncurkan selama jam kerja. Investasikan upaya Anda di muka untuk menentukan dan merencanakan proses penyebaran untuk mendorong keputusan desain utama seperti apakah akan memperlakukan sumber daya sebagai sementara.

Untuk mencapai penyebaran waktu henti nol, sebarkan infrastruktur baru di samping infrastruktur yang ada, uji secara menyeluruh, transisi lalu lintas pengguna akhir, dan hanya kemudian nonaktifkan infrastruktur sebelumnya. Praktik lain, seperti arsitektur unit skala, juga merupakan kuncinya.

Implementasi referensi Mission-Critical Online dan Azure Mission-Critical Connected mengilustrasikan pendekatan penyebaran ini, seperti yang ditunjukkan dalam diagram ini:

Lingkungan aplikasi

Lihat video berikut untuk ringkasan rekomendasi untuk lingkungan aplikasi.

Anda memerlukan berbagai jenis lingkungan untuk memvalidasi dan menggelar operasi penyebaran. Jenisnya memiliki kemampuan dan siklus hidup yang berbeda. Beberapa lingkungan mungkin mencerminkan lingkungan produksi dan berumur panjang, dan yang lain mungkin berumur pendek dan memiliki kemampuan yang lebih sedikit daripada produksi. Menyiapkan lingkungan ini di awal siklus pengembangan membantu memastikan kelincahan, pemisahan aset produksi dan praproduksi, dan pengujian menyeluruh operasi sebelum dilepaskan ke lingkungan produksi. Semua lingkungan harus mencerminkan lingkungan produksi sebanyak mungkin, meskipun Anda dapat menerapkan penyederhanaan ke lingkungan yang lebih rendah sesuai kebutuhan. Diagram ini menunjukkan arsitektur misi penting:

Ada beberapa pertimbangan umum:

• Komponen tidak boleh dibagikan di seluruh lingkungan. Kemungkinan pengecualian adalah appliance keamanan hilir seperti firewall dan lokasi sumber untuk data pengujian sintetis.

• Semua lingkungan harus menggunakan artefak infrastruktur sebagai kode (IaC) seperti templat Terraform atau Azure Resource Manager (ARM).

Lingkungan pengembangan

Lihat video berikut untuk informasi tentang lingkungan pengembangan ephemeral dan validasi fitur otomatis.

Mempertimbangkan rancangan

• Kemampuan. Persyaratan yang lebih rendah untuk keandalan, kapasitas, dan keamanan dapat diterima untuk lingkungan pengembangan.

• Lifecycle. Lingkungan pengembangan harus dibuat sesuai kebutuhan dan ada untuk waktu yang singkat. Siklus hidup yang lebih pendek membantu mencegah penyimpangan konfigurasi dari basis kode dan mengurangi biaya. Selain itu, lingkungan pengembangan sering berbagi siklus hidup cabang fitur.

• Kepadatan. Tim memerlukan beberapa lingkungan untuk mendukung pengembangan fitur paralel. Mereka dapat berdampingan dalam satu langganan.

Rekomendasi desain

• Pertahankan lingkungan dalam langganan khusus dengan konteks yang ditetapkan untuk tujuan pengembangan.

• Gunakan proses otomatis untuk menyebarkan kode dari cabang fitur ke lingkungan pengembangan.

Lingkungan pengujian atau penahapan

Lingkungan ini digunakan untuk pengujian dan validasi. Banyak siklus pengujian dilakukan untuk memastikan penyebaran bebas bug ke produksi. Pengujian yang sesuai untuk beban kerja misi penting dijelaskan di bagian Validasi dan pengujian berkelanjutan .

Mempertimbangkan rancangan

• Kemampuan. Lingkungan ini harus mencerminkan lingkungan produksi untuk keandalan, kapasitas, dan keamanan. Dengan tidak adanya beban produksi, gunakan beban pengguna sintetis untuk memberikan metrik realistis dan input pemodelan kesehatan yang berharga.

• Lifecycle. Lingkungan ini berumur pendek. Mereka harus dihancurkan setelah validasi pengujian selesai.

• Kepadatan. Anda dapat menjalankan banyak lingkungan independen dalam satu langganan. Anda juga harus mempertimbangkan untuk menggunakan beberapa lingkungan, masing-masing dalam langganan khusus.

Catatan

Aplikasi misi penting harus tunduk pada pengujian yang ketat.

Anda dapat melakukan fungsi pengujian yang berbeda dalam satu lingkungan, dan dalam beberapa kasus Anda harus melakukannya. Misalnya, untuk pengujian chaos untuk memberikan hasil yang bermakna, Anda harus terlebih dahulu menempatkan aplikasi di bawah beban sehingga Anda dapat memahami bagaimana aplikasi merespons kesalahan yang disuntikkan. Itulah sebabnya pengujian chaos dan pengujian beban biasanya dilakukan secara paralel.

Rekomendasi desain

• Pastikan bahwa setidaknya satu lingkungan penahapan sepenuhnya mencerminkan produksi untuk memungkinkan pengujian dan validasi seperti produksi. Kapasitas dalam lingkungan ini dapat fleksibel berdasarkan eksekusi aktivitas pengujian.

• Hasilkan beban pengguna sintetis untuk menyediakan kasus pengujian realistis untuk perubahan pada salah satu lingkungan.

  Catatan

  Implementasi referensi Mission Critical Online menyediakan contoh generator beban pengguna.

• Tentukan jumlah lingkungan penahapan dan tujuannya dalam siklus pengembangan dan rilis.

Lingkungan produksi

Mempertimbangkan rancangan

• Kemampuan. Tingkat keandalan, kapasitas, dan fungsi keamanan tertinggi untuk aplikasi diperlukan.

• Lifecycle. Meskipun siklus hidup beban kerja dan infrastruktur tetap sama, semua data, termasuk pemantauan dan pengelogan, membutuhkan manajemen khusus. Misalnya, manajemen diperlukan untuk pencadangan dan pemulihan.

• Kepadatan. Untuk beberapa aplikasi, Anda mungkin ingin mempertimbangkan untuk menggunakan lingkungan produksi yang berbeda untuk memenuhi berbagai fungsi klien, pengguna, atau bisnis.

Rekomendasi desain

Memiliki batas tata kelola yang jelas untuk produksi dan lingkungan yang lebih rendah. Tempatkan setiap jenis lingkungan dalam langganan khusus untuk mencapai tujuan tersebut. Segmentasi ini memastikan bahwa pemanfaatan sumber daya di lingkungan yang lebih rendah tidak memengaruhi kuota produksi. Langganan khusus juga mengatur batas akses.

Penyebaran biru/hijau Ephemeral

Model penyebaran biru/hijau memerlukan setidaknya dua penyebaran yang identik. Penyebaran biru adalah penyebaran aktif yang melayani lalu lintas pengguna dalam produksi. Penyebaran hijau adalah penyebaran baru yang disiapkan dan diuji untuk menerima lalu lintas. Setelah penyebaran hijau selesai dan diuji, lalu lintas secara bertahap diarahkan dari biru ke hijau. Jika transfer beban berhasil, penyebaran hijau menjadi penyebaran aktif baru. Penyebaran biru lama kemudian dapat dinonaktifkan melalui proses bertahap. Namun, jika ada masalah dalam penyebaran baru, penyebaran dapat dibatalkan, dan lalu lintas dapat tetap berada dalam penyebaran biru lama atau dialihkan ke penyebaran tersebut.

Azure Mission-Critical merekomendasikan pendekatan penyebaran biru/hijau di mana infrastruktur dan aplikasi disebarkan bersama-sama sebagai bagian dari stempel penyebaran. Jadi meluncurkan perubahan pada infrastruktur atau aplikasi selalu menghasilkan penyebaran hijau yang berisi kedua lapisan. Pendekatan ini memungkinkan Anda untuk sepenuhnya menguji dan memvalidasi efek perubahan terhadap infrastruktur dan aplikasi end-to-end sebelum Anda mengalihkan lalu lintas pengguna ke dalamnya. Pendekatan ini meningkatkan kepercayaan diri dalam merilis perubahan dan memungkinkan peningkatan nol waktu henti karena kompatibilitas dengan dependensi hilir seperti platform Azure, penyedia sumber daya, dan modul IaC dapat divalidasi.

Mempertimbangkan rancangan

• Kemampuan teknologi. Manfaatkan fitur penyebaran bawaan di layanan Azure. Misalnya, Azure App Service menyediakan slot penyebaran sekunder yang dapat ditukar setelah penyebaran. Dengan Azure Kubernetes Service (AKS), Anda dapat menggunakan penyebaran pod terpisah pada setiap simpul dan memperbarui definisi layanan.

• Durasi penyebaran. Penyebaran mungkin membutuhkan waktu lebih lama untuk diselesaikan karena stempel berisi infrastruktur dan aplikasi daripada hanya komponen yang diubah. Namun, ini dapat diterima karena risiko semua komponen tidak berfungsi seperti yang diharapkan mengambil alih kekhawatiran waktu.

• Dampak biaya. Ada biaya tambahan karena dua penyebaran berdampingan, yang harus berdampingan sampai penyebaran selesai.

• Transisi lalu lintas. Setelah penyebaran baru divalidasi, lalu lintas harus ditransisikan dari lingkungan biru ke lingkungan hijau. Transisi ini memerlukan orkestrasi lalu lintas pengguna antara lingkungan. Transisi harus sepenuhnya otomatis.

• Lifecycle. Stempel penyebaran misi-kritis harus dianggap sebagai ephemeral. Menggunakan stempel berumur pendek menciptakan awal yang baru setiap kali, sebelum sumber daya disediakan.

Rekomendasi desain

• Mengadopsi pendekatan penyebaran biru/hijau untuk merilis semua perubahan produksi. Sebarkan semua infrastruktur dan aplikasi setiap kali, untuk semua jenis perubahan, untuk mencapai status yang konsisten dan waktu henti nol. Meskipun Anda dapat menggunakan kembali lingkungan, kami tidak merekomendasikannya untuk beban kerja misi penting. Perlakukan setiap stempel penyebaran regional sebagai sementara dengan siklus hidup yang terkait dengan satu rilis.

• Gunakan load balancer global, seperti Azure Front Door, untuk mengatur transisi otomatis lalu lintas pengguna antara lingkungan biru dan hijau.

• Untuk transisi lalu lintas, tambahkan titik akhir back-end hijau yang menggunakan lalu lintas rendah ke bobot volume, seperti 10 persen. Setelah Anda memverifikasi bahwa volume lalu lintas rendah pada penyebaran hijau berfungsi dan memberikan kesehatan aplikasi yang diharapkan, secara bertahap meningkatkan lalu lintas. Saat melakukannya, terapkan periode ramp-up singkat untuk menangkap kesalahan yang mungkin tidak segera terlihat.

  Setelah semua lalu lintas ditransisikan, hapus back end biru dari koneksi yang ada. Misalnya, hapus back end dari layanan load balancer global, kosongkan antrean, dan lepaskan asosiasi lainnya. Melakukannya membantu mengoptimalkan biaya pemeliharaan infrastruktur produksi sekunder dan memastikan bahwa lingkungan baru bebas dari penyimpangan konfigurasi.

  Pada titik ini, nonaktifkan lingkungan biru lama dan sekarang tidak aktif. Untuk penyebaran berikutnya, ulangi proses dengan biru dan hijau terbalik.

Penyebaran cakupan langganan

Bergantung pada persyaratan skala aplikasi, Anda mungkin memerlukan beberapa langganan produksi untuk berfungsi sebagai unit skala.

Lihat video berikut untuk mendapatkan gambaran umum rekomendasi untuk cakupan langganan untuk aplikasi misi penting.

Mempertimbangkan rancangan

• Skalabilitas. Untuk skenario aplikasi skala tinggi dengan volume lalu lintas yang signifikan, rancang solusi untuk menskalakan di beberapa langganan Azure sehingga batas skala langganan tunggal tidak membatasi skalabilitas.

  Penting

  Penggunaan beberapa langganan mengharuskan kompleksitas CI/CD tambahan, yang harus dikelola dengan tepat. Oleh karena itu, kami merekomendasikan beberapa langganan hanya dalam skenario skala ekstrem, di mana batas satu langganan kemungkinan akan menjadi batasan.

• Batas lingkungan. Sebarkan lingkungan produksi, pengembangan, dan pengujian ke dalam langganan terpisah. Praktik ini memastikan bahwa lingkungan yang lebih rendah tidak berkontribusi terhadap batas skala. Ini juga mengurangi risiko pembaruan lingkungan bawah yang mencemari produksi dengan memberikan manajemen dan batas identitas yang jelas.

• Pemerintahan. Saat Anda memerlukan beberapa langganan produksi, pertimbangkan untuk menggunakan grup manajemen aplikasi khusus untuk menyederhanakan penetapan kebijakan melalui batas agregasi kebijakan.

Rekomendasi desain

• Sebarkan setiap stempel penyebaran regional dalam langganan khusus untuk memastikan bahwa batas langganan hanya berlaku dalam konteks stempel penyebaran tunggal dan tidak di seluruh aplikasi secara keseluruhan. Jika sesuai, Anda mungkin mempertimbangkan untuk menggunakan beberapa stempel penyebaran dalam satu wilayah, tetapi Anda harus menyebarkannya di seluruh langganan independen.

• Tempatkan sumber daya bersama global dalam langganan khusus untuk mengaktifkan penyebaran langganan regional yang konsisten. Hindari menggunakan penyebaran khusus untuk wilayah utama.

Validasi dan pengujian berkelanjutan

Pengujian adalah aktivitas penting yang memungkinkan Anda untuk sepenuhnya memvalidasi kesehatan kode aplikasi dan infrastruktur Anda. Lebih khusus lagi, pengujian memungkinkan Anda memenuhi standar Anda untuk keandalan, performa, ketersediaan, keamanan, kualitas, dan skala. Pengujian harus didefinisikan dan diterapkan dengan baik sebagai bagian dari desain aplikasi dan strategi DevOps Anda. Pengujian adalah masalah utama selama proses pengembang lokal ( perulangan dalam) dan sebagai bagian dari siklus hidup DevOps lengkap ( perulangan luar), yaitu ketika kode dimulai pada jalur dari proses alur rilis menuju lingkungan produksi.

Lihat video berikut untuk mendapatkan gambaran umum validasi dan pengujian berkelanjutan.

Bagian ini berfokus pada pengujian perulangan luar. Ini menjelaskan berbagai jenis pengujian.

Uji	Deskripsi
Pengujian Unit	Mengonfirmasi bahwa logika bisnis aplikasi berfungsi seperti yang diharapkan. Memvalidasi efek keseluruhan perubahan kode.
Pengujian asap	Mengidentifikasi apakah infrastruktur dan komponen aplikasi tersedia dan berfungsi seperti yang diharapkan. Biasanya, hanya satu sesi pengguna virtual yang diuji. Hasilnya harus sistem merespons dengan nilai dan perilaku yang diharapkan. Skenario pengujian asap umum termasuk mencapai titik akhir HTTPS aplikasi web, mengkueri database, dan mensimulasikan alur pengguna dalam aplikasi.
pengujian UI	Memvalidasi bahwa antarmuka pengguna aplikasi disebarkan dan interaksi antarmuka pengguna berfungsi seperti yang diharapkan. Anda harus menggunakan alat otomatisasi UI untuk mendorong otomatisasi. Selama pengujian UI, skrip harus meniadakan skenario pengguna yang realistis dan menyelesaikan serangkaian langkah untuk menjalankan tindakan dan mencapai hasil yang dimaksudkan.
Pengujian beban	Memvalidasi skalabilitas dan operasi aplikasi dengan meningkatkan beban dengan cepat dan/atau secara bertahap hingga ambang batas yang telah ditentukan tercapai. Pengujian beban biasanya dirancang di sekitar alur pengguna tertentu untuk memverifikasi bahwa persyaratan aplikasi terpenuhi di bawah beban yang ditentukan.
Pengujian stres	Menerapkan aktivitas yang membebani sumber daya yang ada untuk menentukan batas solusi dan memverifikasi kemampuan sistem untuk pulih dengan baik. Tujuan utamanya adalah untuk mengidentifikasi potensi penyempitan performa dan batas skala. Sebaliknya, turunkan skala sumber daya komputasi sistem dan pantau bagaimana perilakunya di bawah beban dan tentukan apakah dapat pulih.
Pengujian performa	Menggabungkan aspek pengujian beban dan stres untuk memvalidasi performa di bawah beban dan menetapkan perilaku tolok ukur untuk operasi aplikasi.
Pengujian kekacauan	Menyuntikkan kegagalan buatan ke dalam sistem untuk mengevaluasi bagaimana reaksinya dan untuk memvalidasi efektivitas langkah-langkah ketahanan, prosedur operasional, dan mitigasi. Mematikan komponen infrastruktur, dengan sengaja menurunkan performa, dan memperkenalkan kesalahan aplikasi adalah contoh pengujian yang dapat digunakan untuk memverifikasi bahwa aplikasi akan bereaksi seperti yang diharapkan ketika skenario benar-benar terjadi.
Uji penetrasi	Memastikan bahwa aplikasi dan lingkungannya memenuhi persyaratan postur keamanan yang diharapkan. Tujuannya adalah untuk mengidentifikasi kerentanan keamanan. Pengujian keamanan dapat mencakup rantai pasokan perangkat lunak end-to-end dan dependensi paket, dengan pemindaian dan pemantauan untuk Kerentanan dan Paparan Umum (CVE) yang diketahui.

Mempertimbangkan rancangan

• Otomatisasi. Pengujian otomatis sangat penting untuk memvalidasi perubahan aplikasi atau infrastruktur secara tepat waktu dan berulang.

• Perintah uji. Urutan di mana pengujian dilakukan adalah pertimbangan penting karena berbagai dependensi, seperti kebutuhan untuk memiliki lingkungan aplikasi yang berjalan. Durasi pengujian juga memengaruhi urutan. Pengujian dengan waktu berjalan yang lebih singkat harus berjalan lebih awal dalam siklus jika memungkinkan untuk meningkatkan efisiensi pengujian.

• Batas skalabilitas. Layanan Azure memiliki batas lunak dan keras yang berbeda. Pertimbangkan untuk menggunakan pengujian beban untuk menentukan apakah risiko sistem melebihinya selama beban produksi yang diharapkan. Pengujian beban juga dapat berguna untuk mengatur ambang yang sesuai untuk penskalaan otomatis. Untuk layanan yang tidak mendukung penskalaan otomatis, pengujian beban dapat membantu Anda menyempurnakan prosedur operasional otomatis.

  Ketidakmampuan komponen sistem, seperti komponen atau database jaringan aktif/pasif, untuk menskalakan dengan tepat dapat membatasi. Pengujian stres dapat membantu mengidentifikasi batasan.

• Analisis mode kegagalan. Memasukkan kesalahan ke dalam aplikasi dan infrastruktur yang mendasar dan mengevaluasi efeknya sangat penting untuk menilai mekanisme redundansi solusi. Selama analisis ini, identifikasi risiko, dampak, dan luasnya dampak (pemadaman parsial atau penuh). Untuk contoh analisis yang dibuat untuk implementasi referensi Mission Critical Online , lihat Risiko pemadaman komponen individual.

• Pemantauan. Anda harus menangkap dan menganalisis hasil pengujian satu per satu dan juga menggabungkannya untuk menilai tren dari waktu ke waktu. Anda harus terus mengevaluasi hasil pengujian untuk akurasi dan cakupan.

Rekomendasi desain

Lihat video berikut untuk melihat bagaimana pengujian ketahanan dapat diintegrasikan dengan alur CI/CD Azure DevOps.

• Pastikan konsistensi dengan mengotomatiskan semua pengujian pada infrastruktur dan komponen aplikasi. Integrasikan pengujian dalam alur CI/CD untuk mengatur dan menjalankannya jika berlaku. Untuk informasi tentang opsi teknologi, lihat Alat DevOps.

• Perlakukan semua artefak pengujian sebagai kode. Mereka harus dipertahankan dan versi dikontrol bersama dengan artefak kode aplikasi lainnya.

• Sejajarkan SLA infrastruktur pengujian dengan SLA untuk siklus penyebaran dan pengujian.

• Jalankan uji asap sebagai bagian dari setiap penyebaran. Jalankan juga uji beban ekstensif bersama dengan tes stres dan chaos untuk memvalidasi bahwa performa dan pengoperasian aplikasi dipertahankan.

  • Gunakan profil beban yang mencerminkan pola penggunaan puncak nyata.
  • Jalankan eksperimen chaos dan uji injeksi kegagalan secara bersamaan dengan uji beban.

  Tip

  Azure Chaos Studio adalah rangkaian asli alat eksperimen chaos. Alat-alat ini memudahkan untuk melakukan eksperimen chaos dan menyuntikkan kesalahan dalam layanan Azure dan komponen aplikasi.

  Chaos Studio menyediakan eksperimen chaos bawaan untuk skenario kesalahan umum dan mendukung eksperimen kustom yang menargetkan infrastruktur dan komponen aplikasi.

• Jika interaksi database, seperti pembuatan rekaman, diperlukan untuk pengujian beban atau asap, gunakan akun pengujian yang telah mengurangi hak istimewa dan membuat data pengujian dapat dipisahkan dari konten pengguna nyata.

• Pindai dan pantau rantai pasokan perangkat lunak end-to-end dan dependensi paket untuk CVE yang diketahui.

  • Gunakan repositori Dependabot for GitHub untuk memastikan repositori secara otomatis diperbarui dengan rilis paket dan aplikasi terbaru yang bergantung padanya.

Penyebaran infrastruktur sebagai kode

Infrastruktur sebagai kode (IaC) memperlakukan definisi infrastruktur sebagai kode sumber yang dikontrol versi bersama dengan artefak aplikasi lainnya. Menggunakan IaC mempromosikan konsistensi kode di seluruh lingkungan, menghilangkan risiko kesalahan manusia selama penyebaran otomatis, dan memberikan keterlacakan dan pembatalan. Untuk penyebaran biru/hijau, penggunaan IaC dengan penyebaran yang sepenuhnya otomatis sangat penting.

Repositori IaC yang sangat penting memiliki dua definisi berbeda yang dipetakan ke sumber daya global dan regional. Untuk informasi tentang jenis sumber daya ini, lihat pola arsitektur inti.

Mempertimbangkan rancangan

• Infrastruktur yang dapat diulang. Sebarkan beban kerja misi penting dengan cara yang menghasilkan lingkungan yang sama setiap saat. IaC harus menjadi model utama.

• Otomatisasi. Semua penyebaran harus sepenuhnya otomatis. Proses manusia rentan akan kesalahan.

Rekomendasi desain

• Terapkan IaC, memastikan bahwa semua sumber daya Azure ditentukan dalam templat deklaratif dan dipertahankan dalam repositori kontrol sumber. Templat disebarkan dan sumber daya disediakan secara otomatis dari kontrol sumber melalui alur CI/CD. Kami tidak merekomendasikan penggunaan skrip imperatif.

• Melarang operasi manual terhadap semua lingkungan. Satu-satunya pengecualian adalah lingkungan pengembang yang sepenuhnya independen.

Alat DevOps

Penggunaan alat penyebaran yang efektif sangat penting untuk keandalan keseluruhan karena proses DevOps memengaruhi fungsi keseluruhan dan desain aplikasi. Misalnya, operasi failover dan skala mungkin bergantung pada otomatisasi yang disediakan oleh alat DevOps. Tim teknik harus memahami efek tidak tersedianya layanan penyebaran sehubungan dengan beban kerja keseluruhan. Alat penyebaran harus dapat diandalkan dan sangat tersedia.

Microsoft menyediakan dua toolset asli Azure, GitHub Actions dan Azure Pipelines, yang dapat secara efektif menyebarkan dan mengelola aplikasi misi penting.

Mempertimbangkan rancangan

• Kemampuan teknologi. Kemampuan GitHub dan Azure DevOps tumpang tindih. Anda dapat menggunakannya bersama-sama untuk mendapatkan yang terbaik dari keduanya. Pendekatan umumnya adalah menyimpan repositori kode di GitHub.com atau GitHub AE saat menggunakan Azure Pipelines untuk penyebaran.

  Ketahui kompleksitas yang ditambahkan saat Anda menggunakan beberapa teknologi. Evaluasi set fitur kaya terhadap keandalan keseluruhan.

• Ketersediaan regional. Dalam hal keandalan maksimum, dependensi pada satu wilayah Azure mewakili risiko operasional.

  Misalnya, misalnya lalu lintas tersebar di dua wilayah: Wilayah 1 dan Wilayah 2. Wilayah 2 menghosting instans alat Azure DevOps. Misalkan ada pemadaman di Wilayah 2 dan instans tidak tersedia. Wilayah 1 secara otomatis menangani semua lalu lintas dan perlu menyebarkan unit skala ekstra untuk memberikan pengalaman failover yang baik. Tetapi tidak akan dapat karena dependensi Azure DevOps di Wilayah 2.

• Replikasi data. Data, termasuk metadata, alur, dan kode sumber, harus direplikasi di seluruh wilayah.

Rekomendasi desain

• Kedua teknologi dihosting dalam satu wilayah Azure, yang mungkin membuat strategi pemulihan bencana Anda membatasi.

  GitHub Actions sangat cocok untuk tugas build (integrasi berkelanjutan) tetapi mungkin tidak memiliki fitur untuk tugas penyebaran yang kompleks (penyebaran berkelanjutan). Mengingat kumpulan fitur Azure DevOps yang kaya, kami merekomendasikannya untuk penyebaran misi penting. Namun, Anda harus membuat pilihan setelah menilai trade-off.

• Tentukan SLA ketersediaan untuk alat penyebaran dan pastikan keselarasan dengan persyaratan keandalan aplikasi yang lebih luas.

• Untuk skenario multi-wilayah yang menggunakan konfigurasi penyebaran aktif/pasif atau aktif/aktif, pastikan bahwa orkestrasi failover dan operasi penskalaan dapat terus berfungsi meskipun toolset penyebaran hosting wilayah utama menjadi tidak tersedia.

Strategi percabangan

Ada banyak pendekatan yang valid untuk percabangan. Anda harus memilih strategi yang memastikan keandalan maksimum. Strategi yang baik memungkinkan pengembangan paralel, menyediakan jalur yang jelas dari pengembangan ke produksi, dan mendukung rilis cepat.

Mempertimbangkan rancangan

• Minimalkan akses. Pengembang harus melakukan pekerjaan mereka di cabang fitur/* dan perbaikan/* . Cabang-cabang ini menjadi titik masuk untuk perubahan. Pembatasan berbasis peran harus diterapkan ke cabang sebagai bagian dari strategi percabangan. Misalnya, hanya mengizinkan administrator untuk membuat cabang rilis atau menerapkan konvensi penamaan untuk cabang.

• Proses yang dipercepat untuk keadaan darurat. Strategi percabangan harus memungkinkan perbaikan digabungkan menjadi utama segera setelah praktis. Dengan begitu, rilis di masa mendatang berisi perbaikan, dan pengulangan masalah dihindari. Gunakan proses ini hanya untuk perubahan kecil yang mengatasi masalah mendesak, dan gunakan dengan pengekangan.

Rekomendasi desain

• Prioritaskan penggunaan GitHub untuk kontrol sumber.

  Penting

  Buat strategi percabangan yang merinci pekerjaan dan rilisfitur sebagai minimum, dan gunakan kebijakan dan izin cabang untuk memastikan bahwa strategi diberlakukan dengan tepat.

• Picu proses pengujian otomatis untuk memvalidasi kontribusi perubahan kode sebelum diterima. Anggota tim juga harus meninjau perubahan.

• Perlakukan cabang utama sebagai cabang yang terus bergerak maju dan stabil yang terutama digunakan untuk pengujian integrasi.

  • Pastikan bahwa perubahan dilakukan hanya melalui PR. Gunakan kebijakan cabang untuk melarang penerapan langsung.
  • Setiap kali PR digabungkan menjadi utama, PR harus secara otomatis memulai penyebaran terhadap lingkungan integrasi.
  • Cabang utama harus dianggap stabil. Harus aman untuk membuat rilis dari utama pada waktu tertentu.

• Gunakan cabang rilis/* khusus yang dibuat dari cabang utama dan digunakan untuk menyebarkan ke lingkungan produksi. cabang rilis/* harus tetap berada di repositori dan dapat digunakan untuk menambal rilis.

• Mendokumenkan proses perbaikan dan menggunakannya hanya jika diperlukan. Buat perbaikan di cabang fix/* untuk penggabungan berikutnya ke cabang rilis dan penyebaran ke produksi.

AI untuk DevOps

Anda dapat menerapkan metodologi AIOps dalam alur CI/CD untuk melengkapi pendekatan pengujian tradisional. Melakukannya memungkinkan deteksi potensi regresi atau degradasi dan memungkinkan penyebaran dihentikan terlebih dahulu untuk mencegah potensi dampak negatif.

Mempertimbangkan rancangan

• Volume data telemetri. Alur CI/CD dan proses DevOps memancarkan berbagai telemetri untuk model pembelajaran mesin. Telemetri berkisar dari hasil pengujian dan hasil penyebaran hingga data operasional tentang komponen pengujian dari tahap penyebaran komposit.

• Skalabilitas. Pendekatan pemrosesan data tradisional seperti Extract, Transform, Load (ETL) mungkin tidak dapat menskalakan throughput untuk mengikuti pertumbuhan telemetri penyebaran dan data pengamatan aplikasi. Anda dapat menggunakan pendekatan analitik modern yang tidak memerlukan ETL dan pergerakan data, seperti virtualisasi data, untuk mengaktifkan analisis berkelanjutan oleh model AIOps.

• Perubahan penyebaran. Perubahan penyebaran perlu disimpan untuk analisis dan korelasi otomatis terhadap hasil penyebaran.

Rekomendasi desain

• Tentukan data proses DevOps untuk dikumpulkan dan cara menganalisisnya. Telemetri, seperti metrik eksekusi pengujian dan data rangkaian waktu perubahan dalam setiap penyebaran, penting.

  • Mengekspos data pengamatan aplikasi dari lingkungan penahapan, pengujian, dan produksi untuk analisis dan korelasi dalam model AIOps.

• Mengadopsi alur kerja MLOps.

• Kembangkan model analitik yang sadar konteks dan sadar dependensi untuk memberikan prediksi dengan rekayasa fitur otomatis untuk mengatasi perubahan skema dan perilaku.

• Operasionalkan model dengan mendaftarkan dan menyebarkan model terlatih terbaik dalam alur penyebaran.

Langkah selanjutnya

Tinjau pertimbangan keamanan.

Keamanan