Rancang alur kerja dan strategi penerapan versi
Ketika Anda mulai menerbitkan kode Bicep yang dapat digunakan kembali, Anda mungkin menggunakan pendekatan manual. Sangat mudah bagi Anda untuk menentukan file Bicep mana yang perlu Anda terbitkan, dan Anda mungkin memiliki proses manual untuk menaikkan nomor versi.
Saat mengotomatiskan proses penerbitan, Anda perlu mempertimbangkan cara mengotomatiskan langkah-langkah ini. Di unit ini, Anda akan mempelajari cara mengadopsi sistem penerapan versi yang mengomunikasikan perubahan yang telah Anda buat pada kode Anda. Anda juga akan mempelajari bagaimana Anda dapat mencakup alur kerja untuk menerbitkan kode yang Anda harapkan saja.
Nomor versi
Dalam modul pelatihan Microsoft Learn sebelumnya, Anda mempelajari tentang pentingnya penerapan versi untuk spesifikasi templat dan modul Bicep. Anda dapat memilih dari berbagai pendekatan penerapan versi. Dalam banyak situasi, ini adalah praktik yang baik untuk menggunakan sistem penerapan versi multipart . Sistem penerapan versi multipihak terdiri dari versi utama , versi minor , dan nomor revisi , mirip dengan contoh berikut:
Dalam contoh sebelumnya, versi utama adalah 1, versi minor adalah 4, dan nomor revisi adalah 106.
Perubahan di berbagai bagian nomor versi mengomunikasikan informasi penting tentang jenis perubahan dalam kode:
Setiap kali Anda membuat perubahan yang melanggar, Anda harus menaikkan nomor versi utama. Misalnya, Anda menambahkan parameter wajib baru atau menghapus parameter dari file Bicep Anda. Ini adalah contoh perubahan yang melanggar, karena Bicep mengharuskan parameter wajib ditentukan pada waktu penyebaran dan tidak mengizinkan nilai pengaturan untuk parameter yang tidak ada. Jadi, Anda akan memperbarui nomor versi utama.
Setiap kali Anda menambahkan sesuatu yang baru ke kode, tetapi itu bukan perubahan yang melanggar, Anda harus menambah nomor versi minor. Misalnya, Anda menambahkan parameter opsional baru dengan nilai default. Parameter opsional tidak melanggar perubahan, jadi Anda harus memperbarui nomor versi minor.
Setiap kali Anda membuat perbaikan bug yang kompatibel dengan mundur atau perubahan lain yang tidak memengaruhi cara kerja kode, Anda harus menaikkan nomor revisi. Misalnya, Anda merefaktor kode Bicep Anda untuk memanfaatkan variabel dan ekspresi dengan lebih baik. Jika refaktor tidak mengubah perilaku kode Bicep sama sekali, Anda memperbarui nomor revisi.
Alur kerja Anda juga dapat mengatur nomor revisi secara otomatis. Nomor eksekusi alur kerja dapat digunakan sebagai nomor revisi. Konvensi ini membantu memastikan bahwa nomor versi Anda selalu unik, bahkan jika Anda tidak memperbarui komponen lain dari nomor versi Anda.
Misalnya, Anda menggunakan modul Bicep yang telah diterbitkan orang lain. Modul ini memiliki nomor versi 2.0.496. Anda melihat bahwa versi baru modul tersedia dengan nomor versi 2.1.502. Satu-satunya perubahan signifikan adalah pada nomor versi minor, yang menunjukkan bahwa Anda seharusnya tidak mengharapkan perubahan yang melanggar saat Anda menggunakan versi baru.
Catatan
penerapan versi Semantik adalah struktur penerapan versi formal yang mirip dengan penerapan versi multipart. Penerapan versi semantik mencakup komponen tambahan dalam nomor versi, bersama dengan aturan ketat tentang kapan Anda harus mengatur atau mengatur ulang setiap komponen. Kami menautkan ke informasi selengkapnya tentang penerapan versi dalam ringkasan.
Tim Anda perlu memutuskan cara menentukan perubahan yang melanggar untuk tujuan penerapan versi. Misalnya, andai Anda memiliki file Bicep yang menyebarkan akun penyimpanan. Anda sekarang memperbarui file Bicep untuk mengaktifkan titik akhir privat di akun penyimpanan Anda. Anda menambahkan zona DNS privat ke file Bicep Anda secara bersamaan.
Dalam contoh tersebut, Anda mungkin dapat membuat perubahan tanpa memengaruhi parameter atau output file Bicep. Dengan begitu, siapa pun yang menyebarkan file mungkin tidak melihat bahwa apa pun berbeda. Tetapi perubahan ini memperkenalkan perbedaan signifikan dalam perilaku sumber daya Anda, sehingga Anda mungkin memutuskan untuk memperlakukannya sebagai pembaruan versi utama.
Anda juga dapat memilih untuk menggunakan strategi penerapan versi yang lebih sederhana, seperti hanya menggunakan nomor eksekusi alur kerja sebagai nomor versi Anda. Meskipun pendekatan ini lebih mudah diterapkan, itu berarti Anda tidak dapat secara efektif mengomunikasikan perbedaan antara versi kepada siapa pun yang menggunakan kode Anda.
Versi dan alur kerja
Saat Anda menerbitkan kode secara interaktif, seperti dengan menggunakan Azure CLI, Anda mungkin memikirkan nomor versi yang Anda tetapkan ke spesifikasi atau modul templat saat menerbitkannya. Tetapi dalam alur kerja penyebaran otomatis, Anda perlu mengubah pendekatan Anda untuk menetapkan nomor versi. Alur kerja Anda tidak dapat mendeteksi perubahan yang melanggar secara otomatis, atau memberi tahu Anda kapan Anda harus menaikkan nomor versi utama atau minor Anda. Pertimbangkan penerapan versi dengan cermat sebelum Anda menerbitkan spesifikasi atau modul templat.
Salah satu pendekatannya adalah menyimpan file metadata dengan kode Bicep Anda, seperti yang diilustrasikan dalam diagram berikut:
Setiap kali Anda memperbarui kode Bicep, Anda memperbarui informasi versi dalam file metadata yang sesuai. Pastikan Anda mengidentifikasi perubahan yang melanggar dan tidak terputus dengan benar sehingga Anda dapat menaikkan nomor versi dengan benar.
Petunjuk / Saran
Jika tim Anda meninjau kode Bicep Anda dengan menggunakan permintaan pull, minta peninjau untuk memvalidasi apakah ada perubahan pada kode Anda yang memerlukan perubahan nomor versi utama atau minor Anda.
Anda akan melihat bagaimana Anda dapat menggunakan file metadata di latihan berikutnya.
Berapa banyak alur kerja?
Adalah umum untuk membangun kumpulan spesifikasi dan modul templat. Seringkali, masuk akal untuk menyimpannya di repositori Git yang sama.
Dengan menggunakan filter jalur di GitHub Actions, Anda dapat membuat alur kerja terpisah untuk setiap modul atau spesifikasi templat dalam repositori Anda. Pendekatan ini membantu Anda menghindari penerbitan versi baru setiap file Bicep dalam repositori setiap kali Anda mengubah satu file. Anda dapat menggunakan alur kerja yang dapat digunakan kembali untuk menentukan langkah-langkah alur kerja Anda dalam file terpusat, yang menjaga alur kerja setiap modul dan spesifikasi templat tetap ringan.
Misalnya, Anda memiliki struktur file yang mirip dengan yang diilustrasikan sebelumnya. Anda dapat mengonfigurasi tiga alur kerja terpisah, satu untuk setiap file Bicep. Pilih setiap tab untuk melihat definisi alur kerja yang sesuai dan filter jalurnya:
name: 'publish-module-1'
on:
push:
branches:
- main
paths:
- 'module-1/**'
jobs:
publish:
uses: ./.github/workflows/publish-module.yml
with:
path: 'module-1/main.bicep'
Misalkan Anda hanya mengubah file module-2/main.bicep . Hanya alur kerja untuk modul 2 yang berjalan. Tetapi jika Anda mengubah beberapa file dalam penerapan yang sama, masing-masing alur kerja yang relevan dipicu.
Catatan
Pendekatan membuat alur kerja untuk setiap file Bicep yang dapat digunakan kembali sangatlah sederhana dan fleksibel. Tetapi bisa menjadi rumit ketika Anda memiliki sejumlah besar file Bicep, atau jika Anda tidak ingin mempertahankan alur kerja terpisah untuk setiap modul dan spesifikasi templat.
Anda juga dapat menulis skrip dalam alur kerja untuk menemukan kode yang diubah dan menerbitkan file tersebut saja. Ini adalah pendekatan yang lebih kompleks, dan berada di luar cakupan modul pelatihan Microsoft Learn ini.
Lingkungan untuk kode Bicep yang dapat digunakan kembali
Saat Anda menyebarkan ke Azure dengan menggunakan Bicep, umumnya menggunakan beberapa lingkungan untuk membantu Anda memvalidasi dan menguji kode anda sebelum menerbitkan kode ke lingkungan produksi. Dalam modul pelatihan Microsoft Learn sebelumnya, Anda mempelajari cara bekerja dengan beberapa lingkungan dari alur kerja penyebaran.
Beberapa organisasi menerapkan prinsip yang sama untuk modul Bicep dan spesifikasi templat. Misalnya, Anda mungkin terlebih dahulu menerbitkan versi baru modul Anda ke registri nonproduksi sehingga pengguna setiap modul dapat mencoba versi baru. Kemudian, setelah ditandatangani, Anda dapat menerbitkan modul ke registri produksi organisasi Anda.
Seperti penyebaran reguler, Anda dapat menggunakan pekerjaan dan alur kerja yang dapat digunakan kembali untuk menentukan urutan penyebaran di seluruh lingkungan Anda. Dalam modul pelatihan Microsoft Learn ini, kami menerbitkan ke satu lingkungan untuk menjaga alur kerja tetap sederhana.
Saat Anda menggunakan modul dari registri atau menggunakan spesifikasi templat sebagai modul Bicep, Anda dapat menggunakan alias . Sebagai alternatif menentukan nama registri setiap kali Anda menentukan modul, Anda menggunakan aliasnya.
Dengan menggunakan alias, Anda dapat membuat proses penyebaran berfungsi di beberapa lingkungan. Misalnya, saat menentukan modul, Anda dapat menggunakan alias dari pada nama registri. Kemudian, Anda dapat merancang alur kerja penyebaran untuk mengonfigurasi alias yang akan dipetakan ke:
- Registri modul pengembangan saat Anda menyebarkan ke lingkungan kotak pasir.
- Registri produksi saat Anda menyebarkan ke lingkungan lain.
Catatan
Alias tidak berlaku saat Anda menerbitkan. Ini hanya berfungsi saat Anda menggunakan spesifikasi templat atau modul dalam file Bicep.