Pengembangan berbasis pengujian untuk zona pendaratan Azure
Pengembangan berbasis pengujian (TDD) adalah pengembangan perangkat lunak dan proses DevOps yang meningkatkan kualitas fitur dan peningkatan baru dalam solusi berbasis kode. TDD membuat kasus pengujian unit sebelum mengembangkan kode aktual, dan menguji kode terhadap kasus pengujian. Pendekatan ini berlawanan dengan mengembangkan kode terlebih dahulu dan membuat kasus pengujian nanti.
Zona pendaratan adalah lingkungan untuk menghosting beban kerja yang telah disediakan sebelumnya melalui kode. Zona pendaratan mencakup kemampuan dasar yang menggunakan serangkaian layanan cloud dan praktik terbaik yang ditentukan. Artikel ini menjelaskan pendekatan yang menggunakan TDD untuk menyebarkan zona pendaratan yang berhasil sambil memenuhi persyaratan kualitas, keamanan, operasi, dan tata kelola.
Infrastruktur cloud adalah output dari eksekusi kode. Kode yang terstruktur dengan baik, teruji, dan terverifikasi menghasilkan zona arahan yang layak. Infrastruktur berbasis cloud dan kode sumber yang mendasarnya dapat menggunakan pendekatan ini untuk memastikan bahwa zona pendaratan berkualitas tinggi dan memenuhi persyaratan inti.
Gunakan pendekatan ini untuk memenuhi permintaan fitur sederhana selama pengembangan awal. Nantinya dalam siklus hidup adopsi cloud, Anda dapat menggunakan proses ini untuk memenuhi persyaratan keamanan, operasi, tata kelola, atau kepatuhan. Proses ini sangat berguna untuk mengembangkan dan merefaktor zona pendaratan dalam upaya pengembangan paralel.
Siklus pengembangan berbasis pengujian
Diagram berikut menunjukkan siklus pengembangan berbasis pengujian untuk zona pendaratan Azure:
Buat pengujian. Tentukan pengujian untuk memvalidasi bahwa kriteria penerimaan untuk fitur telah terpenuhi. Otomatiskan pengujian saat Anda mengembangkan, untuk mengurangi jumlah upaya pengujian manual, terutama untuk penyebaran skala perusahaan.
Uji zona pendaratan. Jalankan pengujian baru dan pengujian yang ada. Jika fitur yang diperlukan tidak disertakan dalam penawaran penyedia cloud dan belum disediakan oleh upaya pengembangan sebelumnya, pengujian akan gagal. Menjalankan pengujian yang ada membantu memvalidasi bahwa fitur atau pengujian baru Anda tidak mengurangi keandalan fitur zona pendaratan yang ada.
Perluas dan refaktor zona pendaratan. Tambahkan atau ubah kode sumber untuk memenuhi fitur nilai tambah yang diminta dan tingkatkan kualitas umum basis kode.
Untuk memenuhi kriteria TDD, tim platform cloud hanya akan menambahkan kode untuk memenuhi fitur yang diminta. Namun, kualitas dan pemeliharaan kode adalah upaya bersama. Saat mereka memenuhi permintaan fitur baru, tim platform cloud harus mencoba meningkatkan kode dengan menghapus duplikasi dan mengklarifikasi kode. Menjalankan pengujian antara pembuatan kode baru dan pemfaktoran ulang kode sumber sangat disarankan.
Sebarkan zona pendaratan. Setelah kode sumber memenuhi permintaan fitur, sebarkan zona pendaratan yang dimodifikasi ke penyedia cloud di lingkungan pengujian terkontrol atau kotak pasir.
Uji zona pendaratan. Coba lagi zona pendaratan untuk memvalidasi bahwa kode baru memenuhi kriteria penerimaan untuk fitur yang diminta. Setelah semua pengujian lulus, fitur dianggap lengkap dan kriteria penerimaan dianggap terpenuhi.
Siklus TDD mengulangi langkah-langkah dasar sebelumnya hingga memenuhi definisi lengkap dari selesai. Ketika semua fitur nilai tambah dan kriteria penerimaan lulus pengujian terkait, zona arahan siap mendukung gelombang berikutnya dari rencana adopsi cloud.
Siklus yang membuat TDD efektif sering disebut sebagai tes merah/hijau. Dalam pendekatan ini, tim platform cloud dimulai dengan pengujian yang gagal, atau pengujian merah, berdasarkan definisi yang dilakukan dan kriteria penerimaan yang ditentukan. Untuk setiap fitur atau kriteria penerimaan, tim platform cloud menyelesaikan tugas pengembangan hingga pengujian lulus, atau memiliki tes hijau.
Tujuan dari TDD adalah untuk mengatasi desain yang lebih baik, bukan untuk membuat serangkaian pengujian. Tes adalah artefak berharga untuk menyelesaikan proses.
Definisi yang dilakukan
Keberhasilan dapat menjadi langkah subjektif yang menyediakan sedikit informasi yang dapat ditindaklanjuti oleh tim platform cloud selama pengembangan atau pemfaktoran ulang zona pendaratan. Kurangnya kejelasan dapat menyebabkan ekspektasi dan kerentanan yang terlewat di lingkungan cloud. Sebelum refaktor tim platform cloud atau memperluas zona pendaratan apa pun, mereka harus mencari kejelasan mengenai definisi selesai (DoD) untuk setiap zona pendaratan.
DoD adalah perjanjian sederhana antara tim platform cloud dan tim lain yang terpengaruh yang menentukan fitur bernilai tambah yang diharapkan untuk disertakan dalam upaya pengembangan zona pendaratan. DoD sering kali merupakan daftar periksa yang selaras dengan rencana adopsi cloud jangka pendek.
Karena tim mengadopsi lebih banyak beban kerja dan fitur cloud, DoD dan kriteria penerimaan menjadi lebih kompleks. Dalam proses yang matang, fitur yang diharapkan masing-masing memiliki kriteria penerimaan mereka sendiri untuk memberikan lebih banyak kejelasan. Ketika fitur bernilai tambah semuanya memenuhi kriteria penerimaan, zona pendaratan cukup dikonfigurasi untuk memungkinkan keberhasilan gelombang adopsi atau rilis saat ini.
Contoh DoD Sederhana
Untuk upaya migrasi awal, DoD mungkin terlalu sederhana. Contoh berikut adalah DoD sederhana:
Zona pendaratan awal akan menghosting 10 beban kerja untuk tujuan pembelajaran awal. Beban kerja ini tidak penting bagi bisnis dan tidak memiliki akses ke data sensitif. Di masa depan, beban kerja ini mungkin akan dirilis ke produksi, tetapi kekritisan dan sensitivitas tidak diharapkan berubah.
Untuk mendukung beban kerja ini, tim adopsi cloud perlu memenuhi kriteria berikut:
- Segmentasi jaringan untuk menyelaraskan dengan desain jaringan yang diusulkan. Lingkungan ini harus menjadi jaringan perimeter dengan akses ke internet publik.
- Akses ke sumber daya komputasi, penyimpanan, dan jaringan untuk menghosting beban kerja yang selaras dengan penemuan digital estate.
- Skema penamaan dan pemberian tag untuk kemudahan penggunaan.
- Selama adopsi, akses sementara bagi tim adopsi cloud untuk mengubah konfigurasi layanan.
- Sebelum rilis produksi, integrasi dengan IdP perusahaan untuk mengatur identitas dan akses yang sedang berlangsung untuk manajemen operasi. Pada saat itu, akses tim adopsi cloud harus dicabut.
Poin terakhir bukan kriteria fitur atau penerimaan, tetapi indikator bahwa lebih banyak ekspansi akan diperlukan dan harus dieksplorasi dengan tim lain lebih awal.
Contoh DoD yang lebih kompleks
Metodologi tata kelola dalam Cloud Adoption Framework memberikan kisah perjalanan kematangan alami tim tata kelola. Tertanam dalam perjalanan tersebut adalah beberapa contoh kriteria DoD dan penerimaan, dalam bentuk pernyataan kebijakan.
Pernyataan kebijakan awal. Contoh DoD awal berdasarkan kebijakan perusahaan yang mengatur persyaratan adopsi tahap awal.
Peningkatan inkremental untuk memperluas manajemen identitas. Contoh kebijakan perusahaan yang mengatur DoD untuk memenuhi persyaratan untuk memperluas manajemen identitas untuk zona pendaratan.
Peningkatan inkremental untuk memperluas persyaratan keamanan. Contoh kebijakan perusahaan yang mengatur DoD untuk memenuhi persyaratan keamanan yang selaras dengan rencana adopsi cloud referensi.
Peningkatan inkremental untuk memperluas manajemen operasi. Contoh kebijakan perusahaan yang mengatur DoD untuk memenuhi persyaratan manajemen operasi dasar.
Peningkatan inkremental untuk memperluas manajemen biaya. Contoh kebijakan perusahaan yang mengatur DoD untuk memenuhi persyaratan manajemen biaya.
Contoh sebelumnya adalah sampel dasar untuk membantu Anda mengembangkan DoD untuk zona pendaratan Anda. Anda bisa mendapatkan sampel kebijakan untuk masing-masing Dari Lima Disiplin Tata Kelola Cloud.
Alat dan fitur Azure untuk mendukung TDD zona pendaratan
Diagram berikut menunjukkan alat pengembangan berbasis pengujian yang tersedia di Azure:
Anda dapat dengan mudah mengintegrasikan alat dan fitur Azure ini ke dalam TDD untuk pembuatan zona pendaratan. Alat ini melayani tujuan tertentu, sehingga lebih mudah untuk mengembangkan, menguji, dan menyebarkan zona pendaratan selaras dengan siklus TDD.
Azure Resource Manager menyediakan platform yang konsisten untuk proses build dan penyebaran. Platform Resource Manager dapat menyebarkan zona pendaratan berdasarkan definisi kode sumber.
Templat Azure Resource Manager (ARM) menyediakan kode sumber utama untuk lingkungan yang disebarkan di Azure. Beberapa alat pihak ketiga seperti Terraform menyediakan templat ARM mereka sendiri untuk dikirimkan ke Azure Resource Manager.
Templat Mulai Cepat Azure menyediakan templat kode sumber yang membantu mempercepat zona pendaratan dan penyebaran beban kerja.
Azure Policy menyediakan mekanisme utama untuk menguji kriteria penerimaan di DoD Anda. Azure Policy juga dapat memberikan deteksi, perlindungan, dan resolusi otomatis saat penyebaran menyimpang dari kebijakan tata kelola.
Dalam siklus TDD, Anda dapat membuat definisi kebijakan untuk menguji satu kriteria penerimaan. Azure Policy menyertakan definisi kebijakan bawaan yang dapat memenuhi kriteria penerimaan individual dalam DoD. Pendekatan ini menyediakan mekanisme untuk pengujian merah sebelum Anda memodifikasi zona pendaratan.
Azure Policy juga menyertakan inisiatif kebijakan bawaan yang dapat Anda gunakan untuk menguji dan menerapkan DoD penuh untuk zona pendaratan. Anda dapat menambahkan semua kriteria penerimaan ke inisiatif kebijakan yang ditetapkan ke seluruh langganan. Setelah zona pendaratan memenuhi DoD, Azure Policy dapat memberlakukan kriteria pengujian untuk menghindari perubahan kode yang akan menyebabkan pengujian gagal dalam rilis mendatang.
Desain dan tinjau Azure Policy sebagai alur kerja Kode sebagai bagian dari pendekatan TDD Anda.
Azure Resource Graph menyediakan bahasa kueri untuk membuat pengujian berbasis data berdasarkan informasi tentang aset yang disebarkan di zona pendaratan. Nanti dalam rencana adopsi, alat ini juga dapat menentukan pengujian kompleks berdasarkan interaksi antara aset beban kerja dan lingkungan cloud yang mendasarinya.
Resource Graph menyertakan sampel kueri tingkat lanjut, yang dapat Anda gunakan untuk memahami bagaimana beban kerja disebarkan dalam zona pendaratan untuk skenario pengujian tingkat lanjut.
Bergantung pada pendekatan pilihan Anda, Anda juga dapat menggunakan alat berikut:
- Menyebarkan zona pendaratan menggunakan Terraform.
- Menyebarkan zona pendaratan menggunakan Bicep.
- Mengelola zona pendaratan menggunakan AzOps, modul PowerShell yang mendorong templat sumber daya dan file Bicep di semua tingkat cakupan Azure, serta menarik dan mengekspor hierarki sumber daya Azure.