Share via

Rekomendasi untuk merancang rantai pasokan pengembangan beban kerja

  • Artikel

Berlaku untuk rekomendasi daftar periksa Azure Well-Architected Framework Operational Excellence ini:

OE:06 Bangun rantai pasokan beban kerja yang mendorong perubahan yang diusulkan melalui alur otomatis yang dapat diprediksi. Alur menguji dan mempromosikan perubahan tersebut di seluruh lingkungan. Optimalkan rantai pasokan untuk membuat beban kerja Anda dapat diandalkan, aman, hemat biaya, dan berkinerja.

Panduan ini menjelaskan rekomendasi untuk merancang rantai pasokan pengembangan beban kerja yang didasarkan pada alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD). Kembangkan rantai pasokan untuk memastikan bahwa Anda memiliki metode yang dapat diprediksi dan terstandarisasi untuk mempertahankan beban kerja Anda. Alur CI/CD adalah manifestasi rantai pasokan, tetapi Anda harus memiliki satu rantai pasokan. Dan Anda mungkin memiliki beberapa alur yang mengikuti proses yang sama dan menggunakan alat yang sama.

Gabungkan rantai pasokan untuk melindungi beban kerja Anda dari kerusakan yang dapat terjadi ketika Anda tidak mengelola perubahan beban kerja dengan benar. Selalu waspadai status beban kerja Anda, sehingga Anda tidak berisiko mengalami perilaku yang tidak dapat diprediksi. Senyawa risiko ini jika Anda perlu menghabiskan waktu kritis untuk menelusuri kembali yang tidak ditemukan untuk perubahan ketika masalah muncul. Untuk meminimalkan risiko ini, standarkan proses dan alat yang menentukan rantai pasokan Anda, dan pastikan bahwa tim beban kerja Anda sepenuhnya berkomitmen terhadap penggunaannya.

Definisi

Istilah Definisi
Rantai pasok Dalam beban kerja cloud, rantai pasokan adalah rangkaian alat dan proses standar yang Anda gunakan untuk memengaruhi perubahan infrastruktur dan aplikasi di seluruh lingkungan.

Strategi desain utama

Catatan

Rekomendasi dalam panduan ini mengacu pada lingkungan beban kerja dalam rantai promosi kode. Sandbox atau lingkungan eksploratif dan bukti konsep lainnya membutuhkan lebih sedikit kekakuan dan struktur.

Tenet inti

Rekomendasi berikut dapat membantu Anda menentukan prinsip inti rantai pasokan Anda.

Buat perubahan beban kerja yang diusulkan melalui proses dan alat rantai pasokan. Terapkan kebijakan ketat penyebaran berbasis templat otomatis. Metode ini membantu memastikan bahwa konfigurasi beban kerja Anda di semua lingkungan terstandarisasi, terdefinisi dengan baik, dan dikontrol dengan ketat. Untuk lingkungan dalam rantai promosi kode, jangan melakukan pembaruan dengan menggunakan proses manual atau interaksi manusia dengan sarana kontrol platform cloud, misalnya portal atau API. Masukkan semua perubahan pada lingkungan melalui alur dengan mengikuti praktik penyebaran yang Anda tentukan. Untuk membantu menerapkan kebijakan ini, pertimbangkan untuk membatasi akses ke baca-saja sebagai default dan menggunakan gerbang otorisasi akses untuk mengizinkan akses tulis.

Aspek penting dari tenet ini adalah bahwa semua perubahan diusulkanberubah sampai disebarkan ke dalam produksi. Melalui pengujian otomatis, seperti integrasi dan pengujian asap, Anda memungkinkan rantai pasokan anda untuk secara otomatis menolak perubahan.

Menyebarkan infrastruktur yang dapat diulang dan tidak dapat diubah sebagai kode (IaC). IaC adalah manajemen infrastruktur dalam model deskriptif yang menggunakan sistem penerapan versi yang mencerminkan kode sumber. Saat Anda membuat aplikasi, kode sumber yang sama harus menghasilkan biner yang sama setiap kali dikompilasi. Dengan cara yang sama, model IaC menghasilkan lingkungan yang sama setiap kali diterapkan.

Masukkan IaC untuk memastikan bahwa tim Anda mengikuti proses standar dan mapan. Beberapa organisasi menunjuk satu individu atau sekelompok kecil individu untuk menyebarkan dan mengonfigurasi infrastruktur. Saat Anda menerapkan proses yang sepenuhnya otomatis, penyebaran infrastruktur memerlukan lebih sedikit manajemen dari individu. Tanggung jawab ditransfer ke proses otomatisasi dan perkakas. Anggota tim dapat memulai penyebaran infrastruktur untuk menjaga konsistensi dan kualitas.

Rancang beban kerja Anda sebagai grup komponen logis yang dapat Anda bundel ke dalam satu templat untuk membuat penyebaran mudah dan dapat diulang. Anda dapat menganggap bundel ini sebagai stempel atau unit skala. Untuk informasi selengkapnya, lihat Pola Stempel Penyebaran. Saat Anda perlu menyebarkan beban kerja untuk menskalakan ke wilayah atau zona lain dalam wilayah yang sama, sebarkan stempel dengan menggunakan alur. Bergantung pada bagaimana Anda merancang stempel, Anda mungkin menyebarkan subset beban kerja Anda alih-alih seluruh beban kerja. Sertakan komponen jaringan dalam alur IaC Anda untuk memastikan bahwa stempel penyebaran Anda secara otomatis tersambung ke sumber daya yang ada.

Untuk mengoptimalkan alur IaC Anda untuk konsistensi dan efisiensi, rancang infrastruktur yang tidak dapat diubah daripada infrastruktur yang dapat diubah. Terapkan infrastruktur yang tidak dapat diubah untuk memastikan bahwa semua sistem dalam cakupan diganti dengan konfigurasi yang diperbarui secara bersamaan dan identik dengan setiap penyebaran.

Gunakan satu set aset kode dan artefak di semua lingkungan dan alur. Titik nyeri umum bagi organisasi adalah ketika lingkungan nonproduksi berbeda dari lingkungan produksi. Membangun lingkungan produksi dan nonproduksi secara manual dapat mengakibatkan konfigurasi yang tidak cocok antara lingkungan. Ketidakcocokan ini memperlambat pengujian dan membuatnya lebih mungkin bahwa perubahan dapat membahayakan sistem produksi. Pendekatan IaC meminimalkan masalah ini. Saat Anda menggunakan otomatisasi IaC, Anda dapat menggunakan file konfigurasi infrastruktur yang sama untuk semua lingkungan untuk menghasilkan lingkungan yang hampir identik. Anda dapat menambahkan parameter ke file konfigurasi infrastruktur dan menyesuaikannya untuk memenuhi persyaratan untuk setiap lingkungan.

Untuk mengontrol biaya, biasanya ada varians antara lingkungan produksi dan nonproduksi. Anda sering tidak memerlukan tingkat redundansi dan performa yang sama di lingkungan nonproduksi seperti yang Anda lakukan dalam produksi. Jumlah dan SKU sumber daya Anda mungkin berbeda di antara lingkungan. Pastikan Anda mengontrol dan memahami varians dengan menggunakan parameter standar untuk membantu Anda mempertahankan prediktabilitas saat membuat perubahan.

Mencerminkan struktur organisasi Anda dalam rantai pasokan dan desain alur Anda. Organisasi Anda mungkin berada di antara tim. Setiap tim mungkin mengelola bagian dari rantai pasokan. Misalnya, banyak organisasi memiliki tim yang mengelola domain infrastruktur, seperti jaringan, data, dan sumber daya komputasi. Tim ini terpisah dari tim pengembangan yang mengelola pengembangan, pengujian, dan penyebaran aplikasi. Di beberapa organisasi, tim pengembangan dan infrastruktur dimasukkan ke dalam tim DevOps yang secara kolektif mengelola semua penyebaran infrastruktur dan aplikasi. Ada banyak cara untuk mengatur tim yang terlibat dalam rantai pasokan. Rantai pasokan Anda bergantung pada semua tim yang bekerja sama dengan lancar. Pastikan semua tim mengikuti proses standar dan menggunakan alat standar untuk membuat rantai pasokan seefisien mungkin.

Rantai pasokan Anda mungkin mengandalkan vendor pihak ketiga jika Anda melakukan outsourcing pada bagian siklus hidup beban kerja. Vendor ini sama pentingnya dengan keberhasilan rantai pasokan Anda sebagai sumber daya internal. Pastikan bahwa ada perjanjian bersama di semua tim tentang proses dan alat yang Anda gunakan.

Menstandarkan metode penyebaran Anda. Bicarakan dengan pemilik produk tentang jumlah waktu henti produksi yang dapat diterima untuk beban kerja Anda. Bergantung pada berapa banyak, jika ada, waktu henti dapat diterima, Anda dapat memilih metode penyebaran yang tepat untuk kebutuhan Anda. Idealnya, Anda harus melakukan penyebaran selama jendela pemeliharaan untuk mengurangi kompleksitas dan risiko. Jika tidak ada waktu henti yang dapat diterima, gunakan metode penyebaran biru-hijau.

Gunakan pendekatan eksposur progresif untuk mengurangi risiko memperkenalkan bug yang tidak terdeteksi kepada pelanggan Anda secara besar-besaran. Juga dikenal sebagai penyebaran kenari, metode ini disebarkan ke grup pengguna yang dikontrol dalam urutan bertahap. Ini menangkap masalah sebelum memengaruhi lebih banyak pengguna. Grup peluncuran awal mungkin merupakan subbagian dari pelanggan Anda yang mengetahui strategi peluncuran. Sub-bagian pelanggan ini dapat mentolerir sejumlah perilaku tak terduga dan memberikan umpan balik. Atau mungkin sekelompok pengguna internal, yang membantu berisi radius ledakan bug selama peluncuran.

Saat Anda menentukan metode penyebaran, adopsi kebijakan standar hanya menyebarkan perubahan terkecil yang layak dalam setiap penyebaran. Tergantung pada faktor-faktor seperti kekritisan beban kerja dan kompleksitas komponen, tentukan perubahan terkecil yang layak. Jika Anda menggunakan infrastruktur yang tidak dapat diubah, perubahan terkecil yang layak biasanya adalah penyebaran sumber daya dengan konfigurasi terbaru untuk menggantikan sumber daya yang menjalankan versi sebelumnya. Jika Anda menggunakan infrastruktur yang dapat diubah, Anda mungkin memutuskan bahwa perubahan terkecil yang layak hanyalah satu pembaruan pada grup sumber daya dalam cakupan.

Ikuti pendekatan berlapis untuk mencerminkan siklus hidup yang berbeda. Lapisan dasar harus tetap statis di sebagian besar siklus hidup beban kerja, dan lapisan aplikasi sering berubah. Untuk memperkirakan perbedaan ini, Anda harus memiliki alur yang berbeda untuk memengaruhi perubahan di setiap lapisan.

Zona pendaratan berada di lapisan terendah. Zona pendaratan adalah pengelompokan logis elemen dasar, seperti langganan, grup manajemen, grup sumber daya, fungsi tata kelola, dan topologi jaringan. Zona pendaratan memungkinkan Anda untuk dengan mudah menyebarkan dan mengelola beban kerja Anda, dan menyediakan tim operasi pusat, atau tim platform, dengan pendekatan berulang untuk konfigurasi lingkungan. Untuk memberikan lingkungan yang konsisten, semua zona pendaratan Azure menyediakan serangkaian area desain umum, arsitektur referensi, implementasi referensi, dan proses untuk memodifikasi penyebaran agar sesuai dengan persyaratan desain Anda. Prinsip desain zona pendaratan Azure memberikan praktik yang direkomendasikan berdasarkan tata kelola berbasis kebijakan bersama demokratisasi langganan. Zona pendaratan harus memerlukan perubahan minimal selama siklus hidup beban kerja Anda. Untuk melihat contoh zona pendaratan, lihat Apa itu zona pendaratan Azure. Arsitektur konseptual ini menyediakan serangkaian pendapat yang direkomendasikan untuk Azure.

Infrastruktur dan fungsi inti Anda, seperti pengontrol jaringan masuk dan keluar, penyeimbangan beban, solusi perutean jaringan, manajemen DNS, dan server inti, juga harus memerlukan perubahan besar yang jarang. Tetapi mereka mungkin memerlukan pembaruan konfigurasi yang sering.

Lapisan aplikasi dan data Anda memerlukan pembaruan konfigurasi yang sering dan perubahan infrastruktur yang sering. Komponen-komponen ini harus memiliki alur yang paling dinamis.

Rencanakan strategi pengujian holistik. Tenet inti keandalan sistem adalah prinsip shift left . Mengembangkan dan menyebarkan aplikasi adalah proses yang digambarkan sebagai serangkaian langkah dari kiri ke kanan. Anda tidak boleh membatasi pengujian hingga akhir proses. Sebanyak mungkin, geser pengujian ke awal, atau ke kiri. Kesalahan lebih murah untuk diperbaiki ketika Anda menangkapnya lebih awal. Mereka bisa mahal atau tidak mungkin untuk diperbaiki nanti dalam siklus hidup aplikasi.

Uji semua kode, termasuk kode aplikasi, templat infrastruktur, dan skrip konfigurasi. Lingkungan yang menjalankan aplikasi harus dikontrol versi dan disebarkan melalui mekanisme yang sama dengan kode aplikasi. Anda dapat menguji dan memvalidasi lingkungan dengan menggunakan paradigma pengujian yang sama dengan yang sudah digunakan tim Anda untuk kode aplikasi.

Jika memungkinkan, gunakan pengujian otomatis untuk memastikan konsistensi. Sertakan jenis pengujian berikut dalam desain rantai pasokan Anda.

  • Pengujian unit: Pengujian unit biasanya dijalankan sebagai bagian dari rutinitas integrasi berkelanjutan. Pengujian unit harus ekstensif dan cepat. Mereka idealnya harus mencakup 100 persen kode dan berjalan dalam waktu kurang dari 30 detik.

    Terapkan pengujian unit untuk memverifikasi bahwa sintaks dan fungsionalitas modul kode individual berfungsi seperti yang seharusnya, misalnya menghasilkan output yang ditentukan untuk input yang diketahui. Anda juga dapat menggunakan pengujian unit untuk memverifikasi bahwa aset IaC valid.

    Terapkan pengujian unit ke semua aset kode, termasuk templat dan skrip.

  • Pengujian asap: Uji asap memverifikasi bahwa beban kerja dapat berdiri di lingkungan pengujian dan berkinerja seperti yang diharapkan. Uji asap tidak memverifikasi interoperabilitas komponen.

    Uji asap memverifikasi bahwa metodologi penyebaran untuk infrastruktur dan aplikasi berfungsi, dan bahwa sistem merespons seperti yang dimaksudkan setelah proses selesai.

  • Pengujian integrasi: Pengujian integrasi memastikan bahwa komponen aplikasi beroperasi satu per satu, lalu menentukan apakah komponen dapat berinteraksi satu sama lain sebagaimana mestinya.

    Dibutuhkan waktu yang cukup lama untuk menjalankan rangkaian pengujian integrasi yang besar. Itu sebabnya yang terbaik adalah menggabungkan prinsip shift kiri dan melakukan pengujian di awal siklus hidup pengembangan perangkat lunak. Tes integrasi cadangan untuk skenario yang tidak dapat Anda uji dengan uji asap atau pengujian unit.

    Anda dapat menjalankan proses pengujian jangka panjang pada interval reguler jika diperlukan. Interval reguler menawarkan kompromi yang baik dan mendeteksi masalah interoperabilitas antara komponen aplikasi tidak lebih dari satu hari setelah diperkenalkan.

    Beberapa skenario pengujian mendapat manfaat dari eksekusi manual. Gunakan pengujian manual saat Anda perlu memperkenalkan elemen interaktivitas manusia ke dalam pengujian.

  • Pengujian penerimaan: Tergantung pada konteksnya, Anda dapat melakukan pengujian penerimaan secara manual. Ini bisa sebagian atau sepenuhnya otomatis. Pengujian penerimaan menentukan apakah sistem perangkat lunak memenuhi spesifikasi persyaratan.

    Tujuan utama pengujian ini adalah untuk mengevaluasi kepatuhan sistem terhadap persyaratan bisnis dan menentukan apakah sistem memenuhi kriteria yang diperlukan untuk pengiriman kepada pengguna akhir.

Terapkan gerbang kualitas di seluruh proses promosi kode Anda melalui pengujian. Sebarkan kode Anda ke lingkungan yang lebih rendah, seperti pengembangan dan pengujian, dan melalui lingkungan yang lebih tinggi, seperti penahapan dan produksi. Saat penyebaran Anda melewati gerbang kualitas, pastikan penyebaran memenuhi target kualitas Anda sebelum perubahan masuk ke produksi. Persyaratan bisnis Anda menentukan apa fokus gerbang kualitas Anda. Pertimbangkan juga prinsip-prinsip dasar Well-Architected Framework: Keamanan, Keandalan, dan Efisiensi Performa.

Integrasikan juga alur kerja persetujuan ke dalam gerbang kualitas Anda. Tentukan dan otomatiskan alur kerja persetujuan dengan jelas jika sesuai. Tentukan kriteria penerimaan kualitas ke dalam otomatisasi Anda, sehingga Anda dapat bergerak melalui gerbang Anda secara efisien dan aman.

Fasilitasi Azure

Azure DevOps adalah kumpulan layanan yang membantu Anda membangun praktik pengembangan kolaboratif, efisien, dan konsisten.

Azure Pipelines menyediakan layanan build dan rilis untuk mendukung CI/CD di aplikasi Anda.

GitHub Actions for Azure terintegrasi dengan Azure untuk menyederhanakan penyebaran. Gunakan GitHub Actions untuk mengotomatiskan proses CI/CD. Anda dapat membuat alur kerja yang membangun dan menguji setiap permintaan pull ke repositori Anda, atau menyebarkan permintaan pull gabungan ke produksi.

Anda dapat menggunakan Terraform, Bicep, dan Azure Resource Manager untuk penyebaran IaC. Bergantung pada kebutuhan Anda dan keakraban tim Anda dengan alat, Anda mungkin menggunakan satu atau beberapa alat ini untuk penyebaran dan manajemen sumber daya Anda.

Contoh

Untuk contoh yang memperlihatkan cara menggunakan Azure Pipelines untuk membangun alur CI/CD, lihat Arsitektur garis besar Azure Pipelines.

Daftar periksa Keunggulan Operasi

Lihat serangkaian rekomendasi lengkap.

Daftar periksa Keunggulan Operasional