Bagikan melalui

Alur rilis klasik

  • Artikel

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:

  1. 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.

  2. Pekerjaan penyebaran antrean:

    Azure Pipelines menjadwalkan pekerjaan penyebaran pada Agen yang tersedia.

  3. Pilihan agen:

    Agen yang tersedia mengambil pekerjaan penyebaran. Alur rilis dapat dikonfigurasi untuk memilih agen yang sesuai secara dinamis selama runtime.

  4. Unduh artefak:

    Agen mengambil dan mengunduh semua artefak yang ditentukan dalam rilis.

  5. Jalankan tugas penyebaran:

    Agen menjalankan semua tugas dalam pekerjaan penyebaran.

  6. Hasilkan log kemajuan:

    Agen menghasilkan log komprehensif untuk setiap langkah penyebaran dan mengirimkannya kembali ke Azure Pipelines.

  7. 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.

Cuplikan layar memperlihatkan langkah-langkah penyebaran di Azure Pipelines.

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.

Cuplikan layar memperlihatkan langkah-langkah penyebaran alur rilis.

Rilis vs penyebaran

Rilis adalah konstruksi yang menyimpan sekumpulan artefak versi yang ditentukan dalam alur CI/CD. Ini termasuk rekam jepret dari semua informasi yang diperlukan untuk melakukan semua tugas dan tindakan dalam alur rilis, seperti tahapan, tugas, kebijakan seperti pemicu dan pemberi persetujuan, dan opsi penyebaran. Mungkin ada beberapa rilis dari satu alur rilis, dan informasi tentang masing-masing disimpan dan ditampilkan di Azure Pipelines untuk periode retensi yang ditentukan.

Penyebaran adalah tindakan menjalankan tugas untuk satu tahap, yang dapat mencakup menjalankan pengujian otomatis, menyebarkan artefak build, dan tindakan lain apa pun yang ditentukan untuk tahap tersebut. Memulai rilis memulai setiap penyebaran berdasarkan pengaturan dan kebijakan yang ditentukan dalam alur rilis asli. Mungkin ada beberapa penyebaran dari setiap rilis bahkan untuk satu tahap. Ketika penyebaran rilis gagal untuk tahap, Anda dapat menyebarkan ulang rilis yang sama ke tahap tersebut. Untuk menyebarkan ulang rilis, cukup navigasikan ke rilis yang ingin Anda sebarkan dan pilih sebarkan.

Diagram berikut menunjukkan hubungan antara rilis, alur rilis, dan penyebaran.

Diagram yang mengilustrasikan perbedaan antara rilis dan penyebaran.

FAQ

T: Mengapa penyebaran saya tidak dipicu?

A: Membuat alur rilis tidak secara otomatis memulai penyebaran. Berikut adalah beberapa alasan mengapa hal ini mungkin terjadi:

  • Pemicu Penyebaran: pemicu penyebaran yang ditentukan dapat menyebabkan penyebaran dijeda. Ini dapat terjadi dengan pemicu terjadwal atau ketika ada penundaan hingga penyebaran ke tahap lain selesai.

  • Kebijakan Antrean: kebijakan ini menentukan urutan eksekusi dan kapan rilis diantrekan untuk penyebaran.

  • Persetujuan Pra-Penyebaran atau Gerbang: tahap tertentu mungkin memerlukan persetujuan atau gerbang pra-penyebaran, mencegah penyebaran hingga semua kondisi yang ditentukan terpenuhi.

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.

Cuplikan layar yang menunjukkan cara mengaktifkan fitur yang dapat diatur pada waktu rilis.

Selanjutnya, saat menghasilkan rilis baru, Anda memiliki kemampuan untuk memodifikasi nilai variabel tersebut.

Cuplikan layar yang menunjukkan cara mengedit variabel pada waktu rilis.

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.

Cuplikan layar yang menunjukkan cara meninggalkan rilis.

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.