Mengatur kebijakan retensi untuk build, rilis, dan pengujian

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

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

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

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

• Perusahaan
• Profesional Pengujian
• Platform MSDN

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

   

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 anda ingin menyimpan setiap eksekusi sebelum menghapusnya.

1. Buka tab Pengaturan 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 buat 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 eksekusi release terbaru cabang dipertahankan. Selain itu, tiga eksekusi terbaru dari alur ini (terlepas dari cabang) juga dipertahankan.

  Untuk memperjelas logika ini lebih lanjut, mari kita katakan 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):

  Lari #	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	branch2	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
  Eksekusi 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

Informasi berikut dihapus saat eksekusi dihapus:

• Log
• Semua alur 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 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

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

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

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 petunjuknya, lihat Detail eksekusi alur - hapus 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 diatur ulang setiap kali rilis dimodifikasi atau disebarkan ke tahap. Jumlah minimum rilis untuk mempertahankan pengaturan diutamakan selama 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 detail selengkapnya tentang cara kerja retensi rilis.

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

Kebijakan retensi untuk YAML dan alur build 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).

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

Pengaturan kebijakan penyimpanan 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
• 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 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 dihapus. Kebijakan ini tidak dapat ditimpa dalam alur rilis individual.

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 dari tugas Terbitkan Artefak Build karena data yang disimpan dengan tugas Terbitkan Artefak Build akan dibersihkan dan dihapus secara berkala.

YAML

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

Klasik

1. Tambahkan tugas Salin File ke Alur Anda.

2. Konfigurasikan tugas Salin File.

FAQ

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

Tidak. 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 retensi 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 mencegahnya?

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 dipertimbangkan di bawah rilis minimum untuk disimpan untuk tahap hanya ketika penyebaran dimulai pada tahap tersebut. 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 membutuhkan hari maksimum untuk disimpan di antara mereka. Rilis minimum untuk disimpan 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 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 eksekusi. Apakah ada cara untuk mendapatkannya kembali?

Jika Anda yakin bahwa Anda 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 ke Kemampuan Agen>dan mengatur Build.Cleanup 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?

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 versi label kontrol atau tag yang secara otomatis dibuat dari tugas Sumber selama build akan dianggap sebagai bagian dari artefak build dan akan dihapus saat build dihapus.

Jika versi label kontrol atau tag perlu dipertahankan, bahkan ketika build dihapus, ini 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.

Artikel terkait

• Mengontrol berapa lama untuk menyimpan hasil pengujian
• Menghapus artefak pengujian