Alur rilis klasik
Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019
Alur rilis klasik memberi pengembang kerangka kerja untuk menyebarkan aplikasi ke beberapa lingkungan secara efisien dan aman. Dengan menggunakan alur rilis klasik, Anda dapat mengotomatiskan proses pengujian dan penyebaran, menyiapkan strategi penyebaran yang fleksibel, menggabungkan alur kerja persetujuan, dan memastikan transisi aplikasi yang lancar di berbagai tahap.
Bagaimana cara kerja alur rilis
Sebagai bagian dari setiap penyebaran, Azure Pipelines menjalankan langkah-langkah berikut:
Persetujuan pra-penyebaran:
Saat permintaan penyebaran baru dipicu, Azure Pipelines memverifikasi apakah persetujuan pra-penyebaran diperlukan sebelum menyebarkan rilis ke tahap. Jika persetujuan diperlukan, persetujuan akan mengirimkan pemberitahuan email ke pemberi persetujuan yang relevan.
Pekerjaan penyebaran antrean:
Azure Pipelines menjadwalkan pekerjaan penyebaran pada Agen yang tersedia.
Pilihan agen:
Agen yang tersedia mengambil pekerjaan penyebaran. Alur rilis dapat dikonfigurasi untuk memilih agen yang sesuai secara dinamis selama runtime.
Unduh artefak:
Agen mengambil dan mengunduh semua artefak yang ditentukan dalam rilis.
Jalankan tugas penyebaran:
Agen menjalankan semua tugas dalam pekerjaan penyebaran.
Hasilkan log kemajuan:
Agen menghasilkan log komprehensif untuk setiap langkah penyebaran dan mengirimkannya kembali ke Azure Pipelines.
Persetujuan pasca-penyebaran:
Setelah penyebaran ke tahap selesai, Azure Pipelines memverifikasi apakah persetujuan pasca-penyebaran diperlukan untuk tahap tertentu. Jika tidak ada persetujuan yang diperlukan, atau setelah persetujuan yang diperlukan diperoleh, persetujuan akan dilanjutkan untuk memulai penyebaran ke tahap berikutnya.
Model Penyebaran
Alur rilis Azure mendukung berbagai sumber artefak termasuk Jenkins, Azure Artifacts, dan Team City. Contoh berikut mengilustrasikan model penyebaran menggunakan alur rilis Azure:
Dalam contoh berikut, alur terdiri dari dua artefak build yang berasal dari alur build terpisah. Aplikasi ini awalnya disebarkan ke tahap Dev dan kemudian ke dua tahap QA terpisah. Jika penyebaran berhasil di kedua tahap QA, aplikasi akan disebarkan ke Prod ring 1 dan kemudian ke Prod ring 2. Setiap cincin produksi mewakili beberapa instans aplikasi web yang sama, disebarkan ke lokasi yang berbeda di seluruh dunia.
FAQ
T: Bagaimana cara mengedit variabel pada waktu rilis?
A: Di tab Variabel alur rilis Anda, pilih kotak centang Dapat Diatur pada waktu rilis untuk variabel yang ingin Anda ubah saat rilis diantrekan.
Selanjutnya, saat menghasilkan rilis baru, Anda memiliki kemampuan untuk memodifikasi nilai variabel tersebut.
T: Kapan lebih tepat untuk memodifikasi rilis alih-alih alur yang menentukannya?
A: Anda dapat mengedit persetujuan, tugas, dan variabel instans rilis. Namun, pengeditan ini hanya akan berlaku untuk instans tersebut. Jika Anda ingin perubahan diterapkan ke semua rilis mendatang, edit alur rilis sebagai gantinya.
T: Apa skenario di mana fitur "tinggalkan rilis" berguna?
J: Jika Anda tidak berencana untuk menggunakan kembali rilis, atau ingin mencegahnya digunakan, Anda dapat meninggalkan rilis sebagai berikut Alur> (...) >Abaikan. Anda tidak dapat meninggalkan rilis saat penyebaran sedang berlangsung, Anda harus membatalkan penyebaran terlebih dahulu.
T: Bagaimana cara mengelola penamaan rilis baru?
A: Konvensi penamaan default untuk alur rilis adalah penomoran berurutan, di mana rilis diberi nama Release-1, Release-2, dan sebagainya. Namun, Anda memiliki fleksibilitas untuk menyesuaikan skema penamaan dengan memodifikasi masker format nama rilis. Di tab Opsi dari alur rilis Anda, navigasikan ke halaman Umum dan sesuaikan properti Format nama rilis agar sesuai dengan preferensi Anda.
Saat menentukan format mask, Anda dapat menggunakan variabel yang telah ditentukan sebelumnya berikut. Contoh: Format nama rilis berikut: Release $(Rev:rrr) untuk build $(Build.BuildNumber) $(Build.DefinitionName) akan membuat rilis berikut: Rilis 002 untuk build 20170213.2 MySampleAppBuild.
| Variabel | Deskripsi |
|---|---|
| Rev: rr | Nomor autoincremented dengan setidaknya jumlah digit yang ditentukan. |
| Tanggal / Tanggal: MMddyy | Tanggal saat ini, dengan format default MMddyy. Kombinasi M/MM/MMM/MMMM, d/dd/ddd/ddd/dddd, y/yy/yyyy/yyyy, h/hh/H/HH, m/mm, s/ss didukung. |
| System.TeamProject | Nama proyek tempat build ini berada. |
| Release.ReleaseId | ID rilis, yang unik di semua rilis dalam proyek. |
| Release.DefinitionName | Nama alur rilis tempat rilis saat ini berada. |
| Build.BuildNumber | Jumlah build yang terkandung dalam rilis. Jika rilis memiliki beberapa build, ini adalah jumlah build utama. |
| Build.DefinitionName | Nama alur build yang terkandung dalam rilis. Jika rilis memiliki beberapa build, itu adalah nama alur build utama. |
| Artifact.ArtifactType | Jenis sumber artefak yang ditautkan dengan rilis. Misalnya, ini bisa berupa Azure Pipelines atau Jenkins. |
| Build.SourceBranch | Cabang sumber artefak utama. Untuk Git, ini adalah bentuk utama jika cabang adalah refs/heads/main. Untuk Kontrol Versi Team Foundation, ini adalah cabang formulir jika jalur server akar untuk ruang kerja adalah $/teamproject/branch. Variabel ini tidak diatur untuk Jenkins atau sumber artefak lainnya. |
| Variabel kustom | Nilai properti konfigurasi global yang ditentukan dalam alur rilis. Anda dapat memperbarui nama rilis dengan variabel kustom menggunakan perintah Pengelogan rilis |
T: Bagaimana cara menentukan periode retensi untuk rilis saya?
A: Lihat kebijakan retensi untuk mempelajari cara menyiapkan kebijakan retensi untuk alur rilis Anda.