Bagikan melalui

Mengatur kebijakan retensi untuk kompilasi, rilis, dan pengujian

Layanan Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Kebijakan retensi memungkinkan Anda mengatur berapa lama waktu yang dibutuhkan untuk menyimpan eksekusi, perilisan, dan pengujian yang tersimpan di 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. Pipeline - Atur berapa lama untuk menyimpan artefak, simbol, lampiran, eksekusi, dan pull request yang 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.

Pengaturan kebijakan retensi proyek

Catatan

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

Prasyarat

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

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.

  2. Buka tab ikon gigiPengaturan pengaturan proyek Anda.

  3. Pilih Pengaturan atau Retensi Rilis di bawah Pipelines atau Retensi di bawah Test.

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

    Cuplikan layar pengaturan retensi di pengaturan Proyek.

Penting

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

Mengatur kebijakan retensi proses

Dalam kebanyakan kasus, Anda tidak perlu mempertahankan proses yang selesai lebih dari jumlah hari tertentu. Dengan menggunakan kebijakan retensi, Anda dapat mengontrol berapa hari anda ingin menyimpan setiap eksekusi sebelum menghapusnya.

  1. Buka tab ikon gigiPengaturan pengaturan proyek Anda.

  2. Pilih Pengaturan di bagian Alur.

    • Atur jumlah hari untuk menyimpan artefak, simbol, dan lampiran.
    • Atur jumlah hari untuk menyimpan proses
    • Atur jumlah hari untuk menyimpan run pull request.
    • 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 pemrosesan terbaru yang disimpan untuk setiap pipeline memerlukan penjelasan lebih lanjut. Interpretasi pengaturan ini bervariasi berdasarkan jenis repositori yang Anda buat di alur Anda.

  • Azure Repos: Azure Pipelines mempertahankan jumlah eksekusi terbaru yang dikonfigurasi untuk cabang default pipeline dan untuk setiap cabang-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. Bayangkan jika pipeline's default branch adalah cabang main, dan cabang release memiliki kebijakan pelindungan cabang yang membuatnya menjadi cabang yang dilindungi. Dalam hal ini, jika Anda mengonfigurasi kebijakan untuk mempertahankan tiga eksekusi, maka tiga eksekusi terbaru dari main dan tiga eksekusi terbaru dari cabang release dipertahankan. Selain itu, tiga pengoperasian terbaru dari alur ini juga dipertahankan, terlepas dari cabangnya.

    Untuk memperjelas logika ini lebih lanjut, mari kita nyatakan bahwa daftar eksekusi untuk alur kerja 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):

    Lari # Cabang Dipertahankan/ Tidak dipertahankan Mengapa?
    Jalankan program nomor 10 utama Dipertahankan 3 terbaru untuk yang utama dan 3 terbaru untuk alur
    Jalankan 9 cabang 1 Dipertahankan 3 terbaru untuk alur
    Jalankan 8 cabang2 Dipertahankan 3 terbaru untuk alur
    Jalankan 7 utama Dipertahankan 3 Terbaru untuk Halaman Utama
    Jalankan 6 utama Dipertahankan 3 Terbaru untuk Halaman Utama
    Berlari 5 utama Tidak dipertahankan Tidak ada yang terbaru untuk 3 utama, maupun untuk pipeline
    Jalankan 4 utama Tidak dipertahankan Tidak ada yang terbaru untuk 3 utama, maupun untuk pipeline
    Jalankan 3 cabang 1 Tidak dipertahankan Tidak ada yang terbaru untuk 3 utama, maupun untuk pipeline
    Jalankan 2 rilis Dipertahankan 3 terbaru dirilis
    Jalankan 1 utama Tidak dipertahankan Tidak ada yang terbaru untuk 3 utama, maupun untuk pipeline

  • Semua repositori Git lainnya: Azure Pipelines mempertahankan jumlah eksekusi terbaru yang dikonfigurasi untuk seluruh alur.

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

Bagian dari perjalanan mana yang dihapus

Informasi berikut dihapus saat proses dijalankan dihapus:

  • Catatan
  • Semua pipa kerja dan artefak build
  • 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 proses dihapus

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

Proses 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 disimpan selamanya
  • Ini tidak dipertahankan dalam rilis

Mengatur sewa retensi secara otomatis pada pelaksanaan pipeline

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

Hak retensi dapat ditambahkan untuk jalannya pipa selama periode tertentu. Misalnya, fungsi alur yang disebarkan ke lingkungan pengujian dapat disimpan untuk durasi yang lebih singkat sementara fungsi alur yang disebarkan ke lingkungan produksi dapat disimpan lebih lama.

Menetapkan pengaturan retensi secara manual pada pengejuluan pipeline

Anda dapat mengatur jalur pipa agar tetap dipertahankan secara manual menggunakan menu Tindakan lainnya di halaman detail jalur pipa.

mempertahankan proses secara manual

Menghapus eksekusi

Anda dapat menghapus rangkaian menggunakan Menu Tindakan Lain di Halaman Detail Rangkaian Pipa.

Catatan

Jika ada kebijakan retensi yang saat ini berlaku untuk pelaksanaan, kebijakan tersebut harus dihapus sebelum pelaksanaan dapat dihapus. Untuk petunjuknya, lihat Detail proses alur - hapus proses.

Tim produk secara aktif berupaya meningkatkan waktu penghapusan data. Anda mungkin melihat penundaan pemrosesan beberapa hari saat menghapus data jika ada beberapa titik pengujian yang terkait dengan host Anda.

menghapus eksekusi

Mengatur kebijakan retensi untuk 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.

Pengatur waktu retensi pada rilis diatur ulang setiap kali rilis dimodifikasi atau disebarkan ke tahapan. Jumlah minimum rilis untuk mempertahankan pengaturan diutamakan dibandingkan jumlah hari. Misalnya, jika Anda menentukan untuk mempertahankan minimal tiga rilis, tiga yang 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 rincian lebih lanjut tentang mekanisme retensi rilis.

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

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

Kebijakan retensi rilis global

Jika Anda menggunakan Server Team Foundation lokal atau Server Azure DevOps, 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 Azure DevOps Services, Anda dapat melihat tetapi tidak mengubah pengaturan ini untuk proyek Anda.

Pengaturan kebijakan retensi rilis global dapat ditinjau 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
  • Di Tempat: 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 definisinya di luar nilai yang ditentukan di sini.

Kebijakan retensi 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 rilis tersebut dihapus. Kebijakan ini tidak dapat digantikan dalam alur rilis individual.

Menetapkan kebijakan retensi tingkat koleksi

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.

Cuplikan layar memperlihatkan cara mengonfigurasi kebijakan retensi tingkat koleksi.

Gunakan tugas Salin File untuk menyimpan data lebih lama

Anda dapat menggunakan tugas Copy Files untuk menyimpan data build dan artefak Anda lebih lama daripada yang ditetapkan 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)'

FAQ

Jika saya menandai rangkaian atau rilis agar tetap ada tanpa batas waktu, apakah kebijakan retensi masih berlaku?

Tidak. Kebijakan penyimpanan alur maupun batas maksimum yang ditetapkan oleh administrator sama sekali tidak diterapkan ketika Anda menandai eksekusi atau rilis individual untuk disimpan tanpa batas waktu. Ini akan tetap ada sampai Anda memutuskan untuk berhenti mempertahankannya tanpa batas waktu.

Bagaimana cara menentukan agar proses yang dijalankan di lingkungan produksi dipertahankan lebih lama?

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

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 mengatur retensi berdasarkan lingkungan tempat build disebarkan.

Saya tidak menandai pengoperasian untuk dipertahankan tanpa batas waktu. Namun, saya melihat sejumlah besar eksekusi dipertahankan. Bagaimana cara mencegahnya?

Ini bisa karena salah satu alasan berikut:

  • Aktivitas ini ditandai oleh seseorang dalam proyek Anda untuk disimpan selamanya.
  • Eksekusi dikonsumsi oleh rilis, dan rilis tersebut memegang kunci retensi pada eksekusi tersebut. Sesuaikan kebijakan penyimpanan rilis seperti yang dijelaskan di atas.

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

Bagaimana cara kerja pengaturan 'jumlah rilis minimum yang harus disimpan'?

Jumlah rilis minimum untuk dipertahankan didefinisikan pada tahap tertentu. 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 dipertimbangkan sebagai rilis minimum yang harus disimpan untuk tahap hanya jika penyebaran dimulai pada tahap tersebut. Baik penyebaran yang berhasil maupun yang gagal diperhitungkan. Rilis yang tertunda persetujuannya 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 menyimpan pengaturan semua tahapan tempat rilis diterapkan dan memilih jumlah hari maksimum untuk dipertahankan di antara mereka. Rilis minimum untuk disimpan diatur pada tingkat tahap dan tidak berubah terlepas dari apakah rilis disebarkan ke beberapa tahap atau tidak. Artefak terkait akan tetap berlaku ketika rilis diterapkan ke tahap di mana pengaturannya ditetapkan sebagai benar.

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

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

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

Satu-satunya cara untuk mempertahankan eksekusi atau rilis lebih lama dari apa 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 secara manual. Silakan hubungi Dukungan Azure DevOps untuk bantuan.

Anda juga dapat menjelajahi kemungkinan penggunaan REST API untuk mengunduh informasi dan artefak tentang eksekusi dan mengunggahnya ke penyimpanan atau repositori artefak Anda sendiri.

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

Jika Anda yakin bahwa Anda kehilangan data karena bug pada layanan, segera ajukan tiket dukungan agar informasi yang hilang dapat dipulihkan. Jika definisi build dihapus secara manual lebih dari seminggu sebelumnya, tidak akan mungkin untuk memulihkannya. Jika proses dihapus seperti yang diharapkan karena kebijakan penyimpanan, tidak akan mungkin untuk memulihkan proses yang hilang.

Bagaimana cara menggunakan kemampuan Build.Cleanup dari agen?

Menetapkan kemampuan pada agen akan menyebabkan pekerjaan pembersihan kolam diarahkan hanya ke agen tersebut, sehingga sisanya bebas untuk mengerjakan tugas rutin. Saat jalur pipa dihapus, artefak yang disimpan di luar Azure DevOps dibersihkan melalui tugas 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 dikonfigurasi, hanya agen tersebut yang akan menjalankan pekerjaan pembersihan, membiarkan agen lainnya bebas untuk terus menjalankan tugas alur kerja. Fungsi pembersihan dapat diaktifkan dengan menavigasi ke Agent>Capabilities dan mengatur Build.Cleanup sama dengan 1.

Apa yang terjadi pada berkas berbagi Artefak ketika build dihapus

Saat build dengan Artefak berbagi berkas dihapus, tugas build baru diantre pada agen build untuk pembersihan berkas-berkas 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. Hal ini memastikan bahwa hasil pengujian dihapus hanya ketika rilis dihapus.

Apakah hasil pengujian manual dihapus?

Tidak. 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 dibuat secara otomatis dari tugas Sumber akan dipertahankan, bahkan jika build dihapus. Namun, setiap label atau tag kontrol versi yang dibuat secara otomatis dari tugas Sources selama build akan dianggap sebagai bagian dari artefak build dan akan dihapus saat build dihapus.

Jika label atau tag kontrol versi perlu dipertahankan, bahkan ketika build dihapus, label harus diterapkan sebagai bagian dari tugas dalam pipeline, diberi label secara manual di luar pipeline, atau build harus dipertahankan untuk waktu yang tidak terbatas.

Apa yang terjadi pada pipa yang dikonsumsi di pipa lain?

Rilis klasik mempertahankan pipeline yang dijalankan secara otomatis.

Apa yang terjadi pada pipa yang dikonsumsi di pipa lain?

Rilis klasik mempertahankan pipeline yang dijalankan 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. Jalur sumber daya akan dipertahankan secara otomatis selama jalur rilis dipertahankan.

  • Last updated on