Menetapkan kebijakan retensi untuk build, rilis, dan pengujian

| Layanan Azure DevOps Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Catatan

Di Microsoft Team Foundation Server (TFS) 2018 dan versi sebelumnya, alur build dan rilis disebut definisi, eksekusi disebut build, koneksi layanan disebut titik akhir layanan, tahapan disebut lingkungan, dan pekerjaan disebut fase.

Kebijakan retensi memungkinkan Anda mengatur berapa lama untuk menyimpan eksekusi, rilis, dan pengujian yang disimpan dalam sistem. Untuk menghemat ruang penyimpanan, Anda ingin menghapus eksekusi, pengujian, dan rilis yang lebih lama.

Kebijakan retensi berikut ini tersedia di Azure DevOps di pengaturan Proyek Anda:

  1. Alur - Atur berapa lama untuk menyimpan artefak, simbol, lampiran, eksekusi, dan permintaan pull berjalan.
  2. Rilis (klasik) - Atur apakah akan menyimpan build dan melihat pengaturan retensi default dan maksimum.
  3. Uji - Atur berapa lama untuk menyimpan eksekusi, hasil, dan lampiran pengujian otomatis dan manual.

Kebijakan retensi pengaturan proyek

Catatan

Jika Anda menggunakan server lokal, Anda juga dapat menentukan default kebijakan penyimpanan untuk proyek dan kapan rilis dihancurkan secara permanen. Pelajari selengkapnya tentang retensi rilis nanti di artikel ini.

Prasyarat

Secara default, anggota grup Kontributor, Admin Build, Admin Proyek, dan Admin Rilis dapat mengelola kebijakan penyimpanan.

Untuk mengelola kebijakan retensi, Anda harus memiliki salah satu langganan berikut:

Anda juga dapat membeli akses bulanan ke Azure Test Plans dan menetapkan tingkat akses Paket Dasar + Pengujian . Lihat Menguji akses menurut peran pengguna.

Mengonfigurasi kebijakan retensi

  1. Masuk ke proyek Anda (https://dev.azure.com/{yourorganization}/{yourproject}).

  2. Buka tab Pengaturanikon geriga di pengaturan proyek Anda.

  3. Pilih Pengaturan atau Retensi rilis di bawah Alur atau Retensi di bawah Uji.

    • Pilih Pengaturan untuk mengonfigurasi kebijakan retensi untuk eksekusi, artefak, simbol, lampiran, dan eksekusi permintaan pull.
    • Pilih Retensi rilis untuk menyiapkan kebijakan retensi rilis Anda dan konfigurasikan kapan harus menghapus atau menghancurkan rilis secara permanen.
    • Pilih Retensi untuk menyiapkan berapa lama untuk menyimpan eksekusi pengujian manual dan otomatis.

    Pengaturan retensi di pengaturan Proyek

Penting

Azure Pipelines tidak lagi mendukung kebijakan retensi per alur. Sebaiknya gunakan aturan retensi tingkat proyek.

Mengatur kebijakan retensi eksekusi

Dalam kebanyakan kasus, Anda tidak perlu mempertahankan eksekusi yang selesai lebih lama dari jumlah hari tertentu. Dengan menggunakan kebijakan retensi, Anda dapat mengontrol berapa hari yang Anda inginkan untuk menjaga setiap eksekusi sebelum menghapusnya.

Seiring dengan menentukan berapa hari untuk mempertahankan eksekusi, Anda juga dapat memutuskan jumlah minimum eksekusi yang harus disimpan untuk setiap alur.

  1. Buka tab Pengaturanikon geriga di pengaturan proyek Anda.

  2. Pilih Pengaturan di bagian Alur.

    • Atur jumlah hari untuk menyimpan artefak, simbol, dan lampiran.
    • Atur jumlah hari untuk menyimpan eksekusi
    • Atur jumlah hari untuk menyimpan eksekusi permintaan pull
    • Atur jumlah eksekusi terbaru yang akan disimpan untuk setiap alur

Peringatan

Azure DevOps tidak lagi mendukung aturan retensi per alur. Satu-satunya cara untuk mengonfigurasi kebijakan retensi untuk YAML dan alur klasik adalah melalui pengaturan proyek yang dijelaskan di atas. Anda tidak dapat lagi mengonfigurasi kebijakan retensi per alur.

Pengaturan untuk jumlah eksekusi terbaru yang disimpan untuk setiap alur memerlukan sedikit penjelasan lebih lanjut. Interpretasi pengaturan ini bervariasi berdasarkan jenis repositori yang Anda bangun di alur Anda.

  • Azure Repos: Azure Pipelines mempertahankan jumlah eksekusi terbaru yang dikonfigurasi untuk cabang default alur dan untuk setiap cabang repositori yang dilindungi. Cabang yang memiliki kebijakan cabang apa pun yang dikonfigurasi dianggap sebagai cabang yang dilindungi.

    Sebagai contoh, pertimbangkan repositori dengan dua cabang, main dan release. pipeline's default branch Bayangkan adalah main cabang, dan release cabang memiliki kebijakan cabang, menjadikannya cabang yang dilindungi. Dalam hal ini, jika Anda mengonfigurasi kebijakan untuk mempertahankan tiga eksekusi, maka tiga eksekusi main terbaru dan tiga release eksekusi terbaru dari cabang dipertahankan. Selain itu, tiga eksekusi terbaru dari alur ini (terlepas dari cabang) juga dipertahankan.

    Untuk memperjelas logika ini lebih lanjut, katakanlah daftar eksekusi untuk alur ini adalah sebagai berikut, dengan eksekusi terbaru di bagian atas. Tabel memperlihatkan eksekusi mana yang akan dipertahankan jika Anda telah mengonfigurasi untuk mempertahankan tiga eksekusi terbaru (mengabaikan efek pengaturan jumlah hari):

    Menjalankan # Cabang Dipertahankan/ Tidak dipertahankan Mengapa?
    Jalankan 10 utama Dipertahankan 3 terbaru untuk utama dan Terbaru 3 untuk alur
    Jalankan 9 cabang1 Dipertahankan 3 terbaru untuk alur
    Jalankan 8 cabang2 Dipertahankan 3 terbaru untuk alur
    Jalankan 7 utama Dipertahankan 3 terbaru untuk utama
    Jalankan 6 utama Dipertahankan 3 terbaru untuk utama
    Jalankan 5 utama Tidak dipertahankan Baik 3 terbaru untuk utama, maupun untuk alur
    Jalankan 4 utama Tidak dipertahankan Baik 3 terbaru untuk utama, maupun untuk alur
    Jalankan 3 cabang1 Tidak dipertahankan Baik 3 terbaru untuk utama, maupun untuk alur
    Jalankan 2 Rilis Dipertahankan 3 terbaru untuk rilis
    Jalankan 1 utama Tidak dipertahankan Baik 3 terbaru untuk utama, maupun untuk alur
  • Semua repositori Git lainnya: Azure Pipelines mempertahankan jumlah eksekusi terbaru yang dikonfigurasi untuk seluruh alur.

  • TFVC: Azure Pipelines mempertahankan jumlah eksekusi terbaru yang dikonfigurasi untuk seluruh alur, terlepas dari cabang.

Bagian eksekusi apa yang dihapus

Saat kebijakan retensi menandai build untuk penghapusan, Anda dapat mengontrol informasi mana yang terkait dengan build dihapus:

  • Buat catatan: Anda dapat memilih untuk menghapus seluruh catatan build atau menyimpan informasi dasar tentang build bahkan setelah build dihapus.
  • Label sumber: Jika Anda memberi label sumber sebagai bagian dari build, maka Anda dapat memilih untuk menghapus tag (untuk Git) atau label (untuk TFVC) yang dibuat oleh build.
  • Hasil pengujian otomatis: Anda dapat memilih untuk menghapus hasil pengujian otomatis yang terkait dengan build (misalnya, hasil yang diterbitkan oleh tugas build Terbitkan Hasil Pengujian).

Informasi berikut dihapus saat build dihapus:

  • Catatan
  • Artefak yang diterbitkan
  • Simbol yang diterbitkan

Informasi berikut dihapus saat eksekusi dihapus:

  • Catatan
  • Semua alur dan membangun artefak
  • Semua simbol
  • Binari
  • Hasil pengujian
  • Jalankan metadata
  • Label sumber (TFVC) atau tag (Git)

Paket universal, NuGet, npm, dan paket lainnya tidak terkait dengan retensi alur.

Kapan eksekusi dihapus

Kebijakan retensi Anda diproses sekali sehari. Waktu kebijakan diproses variabel karena kami menyebarkan pekerjaan sepanjang hari untuk tujuan penyeimbangan beban. Tidak ada opsi untuk mengubah proses ini.

Eksekusi dihapus jika semua kondisi berikut ini benar:

  • Ini melebihi jumlah hari yang dikonfigurasi dalam pengaturan retensi
  • Ini bukan salah satu eksekusi terbaru seperti yang dikonfigurasi dalam pengaturan retensi
  • Ini tidak ditandai untuk dipertahankan tanpa batas waktu
  • Ini tidak dipertahankan oleh rilis

Kebijakan retensi Anda berjalan setiap hari pada pukul 3:00 A.M. UTC. Tidak ada opsi untuk mengubah waktu kebijakan berjalan.

Mengatur sewa retensi secara otomatis pada eksekusi alur

Sewa retensi digunakan untuk mengelola masa pakai eksekusi alur di luar periode retensi yang dikonfigurasi. Sewa retensi dapat ditambahkan atau dihapus pada eksekusi alur dengan memanggil LEASE API. API ini dapat dipanggil dalam alur menggunakan skrip dan menggunakan variabel yang telah ditentukan sebelumnya untuk runId dan definitionId.

Sewa retensi dapat ditambahkan pada eksekusi alur untuk periode tertentu. Misalnya, eksekusi alur yang disebarkan ke lingkungan pengujian dapat dipertahankan untuk durasi yang lebih singkat sementara eksekusi yang disebarkan ke lingkungan produksi dapat dipertahankan lebih lama.

Mengatur sewa retensi secara manual pada eksekusi alur

Anda dapat mengatur eksekusi alur secara manual untuk dipertahankan menggunakan menu Tindakan lainnya di halaman Detail eksekusi alur .

mempertahankan eksekusi secara manual

Menghapus eksekusi

Anda dapat menghapus eksekusi menggunakan menu Tindakan lainnya di halaman Detail eksekusi alur .

Catatan

Jika ada kebijakan retensi yang saat ini berlaku untuk eksekusi, kebijakan tersebut harus dihapus sebelum eksekusi dapat dihapus. Untuk mengetahui petunjuknya, lihat Detail eksekusi alur - menghapus eksekusi.

menghapus eksekusi

Mengatur kebijakan retensi rilis

Kebijakan retensi rilis untuk alur rilis klasik menentukan berapa lama rilis dan eksekusi yang ditautkan ke alur tersebut dipertahankan. Dengan menggunakan kebijakan ini, Anda dapat mengontrol berapa hari Anda ingin menyimpan setiap rilis setelah terakhir dimodifikasi atau disebarkan dan jumlah minimum rilis yang harus dipertahankan untuk setiap alur.

Timer retensi pada rilis direset setiap kali rilis dimodifikasi atau disebarkan ke tahap. Jumlah minimum rilis untuk mempertahankan pengaturan lebih diutamakan daripada jumlah hari. Misalnya, jika Anda menentukan untuk mempertahankan minimal tiga rilis, tiga rilis terbaru akan dipertahankan tanpa batas waktu - terlepas dari jumlah hari yang ditentukan. Namun, Anda dapat menghapus rilis ini secara manual saat Anda tidak lagi memerlukannya. Lihat FAQ di bawah ini untuk detail selengkapnya tentang cara kerja retensi rilis.

Sebagai penulis alur rilis, Anda dapat menyesuaikan kebijakan retensi untuk rilis alur Anda pada tab Retensi .

Kebijakan penyimpanan untuk YAML dan alur build sama. Anda dapat melihat pengaturan retensi alur Anda di Pengaturan Proyek untuk Alur di bagian Pengaturan .

Anda juga dapat mempelajari cara menyesuaikan kebijakan ini berdasarkan tahap demi tahap nanti di artikel ini.

Kebijakan penyimpanan rilis global

Jika Anda menggunakan Team Foundation Server lokal atau Azure DevOps Server, Anda dapat menentukan default kebijakan penyimpanan rilis dan maksimum untuk proyek. Anda juga dapat menentukan kapan rilis dihancurkan secara permanen (dihapus dari tab Dihapus di penjelajah build).

Pengaturan retensi rilis lokal

Jika Anda menggunakan Layanan Azure DevOps, Anda dapat melihat tetapi tidak mengubah pengaturan ini untuk proyek Anda.

Pengaturan kebijakan penyimpanan rilis global dapat dikelola dari pengaturan Retensi rilis proyek Anda:

  • Layanan Azure DevOps: https://dev.azure.com/{organization}/{project}/_settings/release?app=ms.vss-build-web.build-release-hub-group
  • Lokal: https://{your_server}/tfs/{collection_name}/{project}/_admin/_apps/hub/ms.vss-releaseManagement-web.release-project-admin-hub

Kebijakan penyimpanan maksimum menetapkan batas atas berapa lama rilis dapat dipertahankan untuk semua alur rilis. Penulis alur rilis tidak dapat mengonfigurasi pengaturan untuk definisi mereka di luar nilai yang ditentukan di sini.

Kebijakan penyimpanan default menetapkan nilai retensi default untuk semua alur rilis. Penulis alur build dapat mengambil alih nilai-nilai ini.

Kebijakan penghancuran membantu Anda menyimpan rilis untuk jangka waktu tertentu setelah dihapus. Kebijakan ini tidak dapat ditimpa dalam alur rilis individual.

Mengatur kebijakan retensi tingkat pengumpulan

Untuk server lokal, Anda juga dapat mengatur kebijakan retensi tingkat koleksi dengan aturan retensi kustom. Kebijakan retensi ini berlaku untuk alur build Klasik. Halaman di https://{your_server}/{collection_name}/_settings/buildqueue mengatur nilai maksimum dan nilai default Anda.

Mengonfigurasi pengaturan pengumpulan server

Catatan

Di TFS, manajemen retensi rilis dibatasi untuk menentukan jumlah hari, dan ini hanya tersedia di TFS 2015.3 dan yang lebih baru.

Kebijakan retensi khusus tahap

Anda mungkin ingin mempertahankan lebih banyak rilis yang telah disebarkan ke tahap tertentu. Misalnya, tim Anda mungkin ingin menyimpan:

  • Rilis disebarkan ke tahap Produksi selama 60 hari, dengan minimal tiga rilis terakhir yang disebarkan.
  • Rilis yang disebarkan ke tahap Pra-produksi selama 15 hari, dengan minimal satu rilis terakhir yang disebarkan.
  • Rilis yang disebarkan ke tahap QA selama 30 hari, dengan minimal dua rilis terakhir yang disebarkan.
  • Rilis yang disebarkan ke tahap Dev selama 10 hari, dengan minimal satu rilis terakhir yang disebarkan.

Contoh kebijakan penyimpanan berikut untuk alur rilis memenuhi persyaratan di atas:

Mengonfigurasi pengaturan retensi rilis untuk alur rilis

Dalam contoh ini, jika rilis yang disebarkan ke Dev tidak dipromosikan ke QA selama 10 hari, itu adalah kandidat potensial untuk dihapus. Namun, jika rilis yang sama disebarkan ke QA delapan hari setelah disebarkan ke Dev, timer retensinya diatur ulang, dan disimpan dalam sistem selama 30 hari lagi.

Saat menentukan kebijakan kustom per alur, Anda tidak boleh melebihi batas maksimum yang ditetapkan oleh administrator.

Interaksi antara kebijakan retensi build dan rilis

Build yang ditautkan ke rilis memiliki kebijakan penyimpanannya sendiri, yang mungkin lebih pendek dari rilis. Jika Anda ingin mempertahankan build untuk periode yang sama dengan rilis, atur kotak centang Pertahankan artefak terkait untuk tahap yang sesuai. Ini mengambil alih kebijakan penyimpanan untuk build, dan memastikan bahwa artefak tersedia jika Anda perlu menyebarkan ulang rilis tersebut.

Saat Anda menghapus alur rilis, menghapus rilis, atau saat kebijakan penyimpanan menghapus rilis secara otomatis, kebijakan penyimpanan untuk build terkait akan menentukan kapan build tersebut dihapus.

Catatan

Di TFS, interaksi antara build dan retensi rilis tersedia di TFS 2017 dan yang lebih baru.

Mengatur kebijakan retensi pengujian

Anda dapat mengatur kebijakan uji coba manual dan otomatis.

Kebijakan retensi eksekusi pengujian manual

Untuk menghapus hasil pengujian manual setelah jumlah hari tertentu, atur batas retensi di tingkat proyek. Azure DevOps menyimpan hasil pengujian manual yang terkait dengan build, bahkan setelah Anda menghapus build tersebut. Dengan demikian, kebijakan build tidak menghapus hasil pengujian sebelum Anda dapat menganalisis data.

  1. Masuk ke Azure DevOps Anda. Anda akan memerlukan setidaknya izin administrator proyek.

  2. Buka proyek Anda lalu pilih pengaturan proyek ikon gigi di bagian bawah halaman.

mengonfigurasi pengaturan proyek

  1. Di halaman Retensi di bawah bagian Uji, pilih batas berapa lama Anda ingin menyimpan data pengujian manual.

kebijakan retensi pengujian manual

Kebijakan retensi eksekusi pengujian otomatis

Secara default, Azure DevOps menyimpan hasil pengujian otomatis yang terkait dengan build hanya selama Anda menyimpan build tersebut. Untuk menyimpan hasil pengujian setelah menghapus build, edit kebijakan penyimpanan build. Jika Anda menggunakan Git untuk kontrol versi, Anda dapat menentukan berapa lama untuk menyimpan hasil pengujian otomatis berdasarkan cabang.

  1. Masuk ke Azure DevOps. Anda akan memerlukan setidaknya izin tingkat build untuk mengedit alur build.

  2. Buka proyek Anda lalu pilih pengaturan proyek ikon gigi di bagian bawah halaman.

mengelola pengaturan proyek

  1. Pilih ikon gigi Pengaturan di bawah Alur dan ubah kebijakan retensi Anda.

edit pengaturan proyek

Hasil pengujian otomatis lainnya

Untuk membersihkan hasil pengujian otomatis yang tersisa dari build yang dihapus atau hasil pengujian yang tidak terkait dengan build, misalnya, hasil yang diterbitkan dari sistem pengujian eksternal, atur batas retensi di tingkat proyek seperti yang ditunjukkan dalam kebijakan retensi eksekusi pengujian manual

Mengatur kebijakan retensi artefak

Anda dapat mengatur kebijakan retensi artefak untuk eksekusi alur di pengaturan Alur.

  1. Masuk ke proyek Anda, Untuk Layanan Azure DevOps, jalur URL-nya adalah https://dev.azure.com/{yourorganization}/{yourproject}.

  2. Buka pada tab Pengaturanikon gigi dari pengaturan proyek Anda.

  3. Pilih Pengaturan di Alur.

  4. Edit Hari untuk menyimpan artefak, simbol, dan lampiran.

Gunakan tugas Salin File untuk menyimpan data lebih lama

Anda dapat menggunakan tugas Salin File untuk menyimpan data build dan artefak Anda lebih lama dari yang diatur dalam kebijakan retensi. Tugas Salin File lebih disukai daripada tugas Terbitkan Artefak Build karena data yang disimpan dengan tugas Terbitkan Artefak Build akan dibersihkan dan dihapus secara berkala.

- task: CopyFiles@2
  displayName: 'Copy Files to: \\mypath\storage\$(Build.BuildNumber)'
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: '_buildOutput/**'
    TargetFolder: '\\mypath\storage\$(Build.BuildNumber)'

Anda juga dapat menyesuaikan kebijakan ini berdasarkan cabang demi cabang jika Anda membangun dari repositori Git.

Kebijakan penyimpanan build global

Anda dapat menentukan default dan maksimum kebijakan penyimpanan build untuk koleksi proyek. Anda juga dapat menentukan kapan build dihancurkan secara permanen (dihapus dari tab Dihapus di penjelajah build).

  • TFS 2018: https://{your_server}/tfs/DefaultCollection/_admin/_buildQueue

Kebijakan penyimpanan maksimum menetapkan batas atas berapa lama eksekusi dapat dipertahankan untuk semua alur build. Penulis alur build tidak dapat mengonfigurasi pengaturan untuk definisinya di luar nilai yang ditentukan di sini.

Kebijakan penyimpanan default menetapkan nilai retensi default untuk semua alur build. Penulis alur build dapat mengambil alih nilai-nilai ini.

Rilis yang dihancurkan secara permanen membantu Anda menyimpan eksekusi untuk jangka waktu tertentu setelah dihapus. Kebijakan ini tidak dapat ditimpa dalam alur build individual.

Repositori Git

Jika jenis repositori Anda adalah salah satu dari yang berikut ini, Anda dapat menentukan beberapa kebijakan retensi dengan filter cabang:

  • Azure Repos Git atau TFS Git.
  • GitHub.
  • Git lainnya/eksternal.

Misalnya, tim Anda mungkin ingin menyimpan:

  • Cabang pengguna dibangun selama lima hari, dengan minimal satu build yang berhasil atau sebagian berhasil untuk setiap cabang.
  • Cabang utama dan fitur dibangun selama 10 hari, dengan minimal tiga build yang berhasil atau sebagian berhasil untuk masing-masing cabang ini. Anda mengecualikan cabang fitur khusus yang ingin Anda simpan untuk jangka waktu yang lebih lama.
  • Dibangun dari cabang fitur khusus dan semua cabang lainnya selama 15 hari, dengan minimal satu build yang berhasil atau sebagian berhasil untuk setiap cabang.

Contoh kebijakan penyimpanan berikut untuk alur build memenuhi persyaratan di atas:

tentukan kebijakan retensi git

Saat menentukan kebijakan kustom untuk setiap alur, Anda tidak boleh melebihi batas maksimum yang ditetapkan oleh administrator.

Membersihkan build permintaan pull

Jika Anda melindungi cabang Git dengan build permintaan pull, maka Anda dapat menggunakan kebijakan retensi untuk menghapus build yang telah selesai secara otomatis. Untuk melakukannya, tambahkan kebijakan yang menyimpan minimal 0 build dengan filter cabang berikut:

  refs/pull/*

kebijakan retensi untuk build PR

Repositori TFVC dan Subversion

Untuk jenis repositori TFVC dan Subversion, Anda dapat memodifikasi satu kebijakan dengan opsi yang sama seperti yang ditunjukkan di atas.

Urutan kebijakan

Ketika sistem membersihkan build lama, sistem mengevaluasi setiap build terhadap kebijakan dalam urutan yang telah Anda tentukan. Anda dapat menyeret dan meletakkan kebijakan lebih rendah atau lebih tinggi dalam daftar untuk mengubah urutan ini.

Kebijakan "Semua" cabang secara otomatis ditambahkan sebagai kebijakan terakhir dalam urutan evaluasi untuk memberlakukan batas maksimum untuk semua cabang lainnya.

menentukan maks kebijakan penyimpanan git yang ditampilkan dalam alur

FAQ

Jika saya menandai eksekusi atau rilis untuk dipertahankan tanpa batas waktu, apakah kebijakan penyimpanan masih berlaku?

Nomor. Baik kebijakan penyimpanan alur maupun batas maksimum yang ditetapkan oleh administrator tidak diterapkan saat Anda menandai eksekusi atau rilis individual untuk dipertahankan tanpa batas waktu. Ini akan tetap sampai Anda berhenti mempertahankannya tanpa batas waktu.

Bagaimana cara menentukan bahwa eksekusi yang disebarkan ke produksi akan dipertahankan lebih lama?

Jika Anda menggunakan rilis klasik untuk disebarkan ke produksi, maka sesuaikan kebijakan penyimpanan pada alur rilis. Tentukan jumlah hari rilis yang disebarkan ke produksi harus dipertahankan. Selain itu, tunjukkan bahwa eksekusi yang terkait dengan rilis tersebut akan dipertahankan. Ini akan mengambil alih kebijakan retensi eksekusi.

Jika Anda menggunakan alur YAML multi-tahap untuk disebarkan ke produksi, satu-satunya kebijakan penyimpanan yang dapat Anda konfigurasi adalah di pengaturan proyek. Anda tidak dapat menyesuaikan retensi berdasarkan lingkungan tempat build disebarkan.

Saya tidak menandai eksekusi untuk dipertahankan tanpa batas waktu. Namun, saya melihat sejumlah besar eksekusi dipertahankan. Bagaimana cara mencegah hal ini?

Ini bisa karena salah satu alasan berikut:

  • Eksekusi ditandai oleh seseorang dalam proyek Anda untuk dipertahankan tanpa batas waktu.
  • Eksekusi dikonsumsi oleh rilis, dan rilis memegang kunci retensi pada eksekusi ini. Sesuaikan kebijakan penyimpanan rilis seperti yang dijelaskan di atas.

Jika Anda yakin bahwa eksekusi tidak lagi diperlukan atau jika rilis telah dihapus, maka Anda dapat menghapus eksekusi secara manual.

Bagaimana cara kerja pengaturan 'rilis minimum untuk mempertahankan'?

Rilis minimum untuk dipertahankan didefinisikan pada tingkat tahap. Ini menunjukkan bahwa Azure DevOps akan selalu mempertahankan jumlah rilis terakhir yang disebarkan untuk tahap tertentu meskipun rilis berada di luar periode retensi. Rilis akan dianggap di bawah rilis minimum untuk disimpan untuk tahap hanya ketika penyebaran dimulai pada tahap itu. Penyebaran yang berhasil dan gagal dipertimbangkan. Persetujuan rilis yang tertunda tidak dipertimbangkan.

Bagaimana periode retensi diputuskan saat rilis disebarkan ke beberapa tahap yang memiliki periode retensi yang berbeda?

Periode retensi akhir diputuskan dengan mempertimbangkan hari untuk mempertahankan pengaturan semua tahapan di mana rilis disebarkan dan memakan waktu hari maksimal untuk disimpan di antara mereka. Rilis minimum yang harus dipertahankan diatur pada tingkat tahap dan tidak berubah berdasarkan rilis yang disebarkan ke beberapa tahap atau tidak. Pertahankan artefak terkait akan berlaku ketika rilis disebarkan ke tahap yang ditetapkan benar.

Saya menghapus tahap yang saya memiliki beberapa rilis lama. Retensi apa yang akan dipertimbangkan untuk kasus ini?

Saat tahap dihapus, sehingga pengaturan retensi tingkat tahap tidak berlaku sekarang. Azure DevOps akan kembali ke retensi default tingkat proyek untuk kasus tersebut.

Organisasi saya mengharuskan kami untuk mempertahankan build dan rilis lebih lama dari yang diizinkan dalam pengaturan. Bagaimana cara meminta retensi yang lebih lama?

Satu-satunya cara untuk mempertahankan eksekusi atau rilis lebih lama dari yang diizinkan melalui pengaturan retensi adalah dengan menandainya secara manual untuk dipertahankan tanpa batas waktu. Tidak ada cara untuk mengonfigurasi pengaturan retensi yang lebih lama. Anda juga dapat mengeksplorasi kemungkinan menggunakan REST API untuk mengunduh informasi dan artefak tentang eksekusi dan mengunggahnya ke penyimpanan atau repositori artefak Anda sendiri.

Aku kehilangan beberapa eksekusi. Apakah ada cara untuk mendapatkannya kembali?

Jika Anda yakin bahwa Anda telah kehilangan eksekusi karena bug dalam layanan, segera buat tiket dukungan untuk memulihkan informasi yang hilang. Jika definisi build dihapus secara manual lebih dari seminggu sebelumnya, tidak akan mungkin untuk memulihkannya. Jika eksekusi dihapus seperti yang diharapkan karena kebijakan penyimpanan, tidak akan mungkin untuk memulihkan eksekusi yang hilang.

Bagaimana cara menggunakan Build.Cleanup kemampuan agen?

Build.Cleanup Mengatur kemampuan pada agen akan menyebabkan pekerjaan pembersihan kumpulan diarahkan hanya ke agen tersebut, membiarkan sisanya bebas untuk melakukan pekerjaan rutin. Saat eksekusi alur dihapus, artefak yang disimpan di luar Azure DevOps dibersihkan melalui pekerjaan yang dijalankan pada agen. Ketika kumpulan agen jenuh dengan pekerjaan pembersihan, ini dapat menyebabkan masalah. Solusi untuk itu adalah menunjuk subset agen di kumpulan yang merupakan agen pembersihan. Jika ada agen yang telah Build.Cleanup ditetapkan, hanya agen tersebut yang akan menjalankan pekerjaan pembersihan, membiarkan agen lainnya bebas untuk terus menjalankan pekerjaan alur. Fungsi pembersihan dapat diaktifkan dengan menavigasi keKemampuanAgen> dan mengatur Build.Cleanup yang sama dengan 1.

Apa yang terjadi pada Artefak berbagi file saat build dihapus

Saat build dengan Artefak berbagi file dihapus, tugas build baru diantrekan pada agen build untuk membersihkan file tersebut. Agen dipilih untuk melakukan tugas ini berdasarkan kriteria berikut: Apakah ada agen dengan Build.Cleanup kemampuan yang tersedia? Apakah agen yang menjalankan build tersedia? Apakah agen dari kumpulan yang sama tersedia? Apakah agen dari kumpulan serupa tersedia? Apakah ada agen yang tersedia?

Apakah hasil pengujian otomatis yang diterbitkan sebagai bagian dari rilis dipertahankan hingga rilis dihapus?

Hasil pengujian yang diterbitkan dalam tahap rilis dipertahankan seperti yang ditentukan oleh kebijakan penyimpanan yang dikonfigurasi untuk hasil pengujian. Hasil pengujian tidak dipertahankan sampai rilis dipertahankan. Jika Anda memerlukan hasil pengujian selama rilis, atur pengaturan retensi untuk eksekusi pengujian otomatis di pengaturan Proyek yang sesuai dengan Jangan pernah hapus. Ini memastikan hasil pengujian dihapus hanya ketika rilis dihapus.

Apakah hasil pengujian manual dihapus?

Nomor. Hasil pengujian manual tidak dihapus.

Bagaimana cara mempertahankan label atau tag kontrol versi saya?

Perhatian

Setiap label kontrol versi atau tag yang diterapkan selama alur build yang tidak secara otomatis dibuat dari tugas Sumber akan dipertahankan, bahkan jika build dihapus. Namun, label kontrol versi atau tag apa pun yang secara otomatis dibuat dari tugas Sumber selama build dianggap sebagai bagian dari artefak build dan akan dihapus saat build dihapus.

Jika label atau tag kontrol versi perlu dipertahankan, bahkan ketika build dihapus, mereka harus diterapkan sebagai bagian dari tugas dalam alur, diberi label secara manual di luar alur, atau build harus dipertahankan tanpa batas waktu.

Apa yang terjadi pada alur yang dikonsumsi di alur lain?

Rilis klasik mempertahankan alur yang digunakan secara otomatis.

Apa yang terjadi pada alur yang dikonsumsi di alur lain?

Rilis klasik mempertahankan alur yang digunakan secara otomatis. Jika Anda menggunakan YAML, Anda juga dapat membuat alur YAML multi-tahap untuk mewakili rilis Anda dan menggunakan alur YAML lain di dalamnya sebagai sumber daya. Alur sumber daya akan dipertahankan secara otomatis selama alur rilis dipertahankan.