Catatan Rilis Pembaruan 1 Azure DevOpsServer 2020

Komunitas Pengembang | Persyaratan Sistem | Ketentuan Lisensi | Blog DevOps | SHA-1 Hashes

Dalam artikel ini, Anda akan menemukan informasi mengenai rilis terbaru untuk Azure DevOps Server.

Untuk mempelajari lebih lanjut tentang menginstal atau meningkatkan penyebaran Azure DevOps Server, lihat Persyaratan Azure DevOps Server. Untuk mengunduh produk Azure DevOps, kunjungi halaman Unduhan Azure DevOps Server.

Peningkatan langsung ke Azure DevOps Server 2020 didukung dari Azure DevOps Server 2019 atau Team Foundation Server 2015 atau yang lebih baru. Jika penyebaran TFS Anda menggunakan TFS 2010 atau yang lebih lama, Anda perlu melakukan beberapa langkah sementara sebelum melakukan peningkatan ke Azure DevOps Server 2019. Untuk mempelajari lebih lanjut, lihat Menginstal dan mengonfigurasi Azure DevOps lokal.

---

Melakukan Peningkatan dengan Aman dari Azure DevOps Server 2019 ke Azure DevOps Server 2020

Azure DevOps Server 2020 memperkenalkan model retensi eksekusi alur (kompilasi) baru yang berfungsi berdasarkan pengaturan tingkat proyek.

Azure DevOps Server 2020 menangani retensi kompilasi secara berbeda, berdasarkan kebijakan retensi tingkat alur. Konfigurasi kebijakan tertentu menyebabkan eksekusi alur dihapus setelah peningkatan. Eksekusi alur yang telah dipertahankan secara manual atau dipertahankan oleh rilis tidak akan dihapus setelah peningkatan.

Baca posting blog kami untuk informasi lebih lanjut tentang cara meningkatkan dengan aman dari Azure DevOps Server 2019 ke Azure DevOps Server 2020.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 13: 12 Maret 2024

File	SHA-256 Hash
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFE79423018E304503CE728158F56F6

Kami telah merilis Patch 13 untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut:

• Mengatasi masalah di mana Server Proksi berhenti bekerja setelah menginstal Patch 12.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 12: 13 Februari 2024

File	SHA-256 Hash
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

Kami telah merilis Patch 12 untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut:

• Memperbaiki bug di mana ruang disk yang digunakan oleh folder cache proksi dihitung dengan salah dan folder tidak dibersihkan dengan benar.
• CVE-2024-20667: Kerentanan Eksekusi Kode Jarak Jauh Server Azure DevOps.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 11: 12 Desember 2023

File	SHA-256 Hash
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

Kami telah merilis Patch 11 untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut:

• Memperbaiki bug di mana pewarisan keamanan persetujuan pra penyebaran tidak berfungsi dalam tahap alur.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 10: 14 November 2023

Kami telah merilis patch untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut.

• Memperluas daftar karakter yang diizinkan tugas PowerShell untuk validasi parameter Aktifkan argumen tugas shell.

Catatan

Untuk menerapkan perbaikan untuk patch ini, Anda harus mengikuti sejumlah langkah untuk memperbarui tugas secara manual.

Memasang patch

Penting

Kami merilis pembaruan untuk agen Azure Pipelines dengan Patch 8 yang dirilis pada 12 September 2023. Jika Anda tidak menginstal pembaruan agen seperti yang dijelaskan dalam catatan rilis untuk Patch 8, kami sarankan Anda menginstal pembaruan ini sebelum menginstal Patch 10. Versi baru agen setelah menginstal Patch 8 adalah 3.225.0.

Mengonfigurasi TFX

1. Ikuti langkah-langkah dalam dokumentasi pengunggahan tugas ke koleksi proyek untuk menginstal dan masuk dengan tfx-cli.

Memperbarui tugas menggunakan TFX

File	SHA-256 Hash
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Unduh dan ekstrak Tasks20231103.zip.
2. Ubah direktori menjadi file yang diekstrak.
3. Jalankan perintah berikut untuk mengunggah tugas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Persyaratan Alur

Untuk menggunakan perilaku baru, variabel AZP_75787_ENABLE_NEW_LOGIC = true harus diatur dalam alur yang menggunakan tugas yang terpengaruh.

• Pada klasik:

  Tentukan variabel di tab variabel di alur.

• Contoh YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 9: 10 Oktober 2023

Penting

Kami merilis pembaruan untuk agen Azure Pipelines dengan Patch 8 yang dirilis pada 12 September 2023. Jika Anda tidak menginstal pembaruan agen seperti yang dijelaskan dalam catatan rilis untuk Patch 8, kami sarankan Anda menginstal pembaruan ini sebelum menginstal Patch 9. Versi baru agen setelah menginstal Patch 8 adalah 3.225.0.

Kami telah merilis patch. untuk Azure DevOps Server 2020 Update 1.2 yang menyertakan perbaikan untuk yang berikut ini.

• Memperbaiki bug di mana identitas "Pemilik Analisis" ditampilkan sebagai Identitas Tidak Aktif pada mesin peningkatan patch.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 8: 12 September 2023

Kami telah merilis patch untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut.

• CVE-2023-33136: Kerentanan Eksekusi Kode Jarak Jauh Azure DevOps Server.
• CVE-2023-38155: Azure DevOps Server dan Team Foundation Server Elevation of Privilege Vulnerability.

Penting

Sebarkan patch ke lingkungan pengujian dan pastikan bahwa alur lingkungan berfungsi seperti yang diharapkan sebelum menerapkan perbaikan pada produksi.

Catatan

Untuk menerapkan perbaikan untuk patch ini, Anda harus mengikuti sejumlah langkah untuk memperbarui agen dan tugas secara manual.

Memasang patch

1. Unduh dan instal Azure DevOps Server 2020 Update 1.2 patch 8.

Memperbarui agen Azure Pipelines

1. Unduh agen dari: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Gunakan langkah-langkah yang diuraikan dalam dokumentasi agen Windows yang dihost sendiri untuk menyebarkan agen.  

Catatan

AZP_AGENT_DOWNGRADE_DISABLED harus diatur ke "true" untuk mencegah agen diturunkan tingkatnya. Di Windows, perintah berikut dapat digunakan dalam prompt perintah administratif, diikuti dengan boot ulang. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Mengonfigurasi TFX

1. Ikuti langkah-langkah dalam dokumentasi pengunggahan tugas ke koleksi proyek untuk menginstal dan masuk dengan tfx-cli.

Memperbarui tugas menggunakan TFX

1. Unduh dan ekstrak Tasks_20230825.zip.
2. Ubah direktori menjadi file yang diekstrak.
3. Jalankan perintah berikut untuk mengunggah tugas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Persyaratan Alur

Untuk menggunakan perilaku baru, variabel AZP_75787_ENABLE_NEW_LOGIC = true harus diatur dalam alur yang menggunakan tugas yang terpengaruh.

• Pada klasik:

  Tentukan variabel di tab variabel di alur.

• Contoh YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 7: 8 Agustus 2023

Kami telah merilis patch untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut.

• CVE-2023-36869: Kerentanan Spoofing Server Azure DevOps.
• Perbarui layanan SSH untuk mendukung SHA2-256 dan SHA2-512. Jika Anda memiliki file konfigurasi SSH yang dikodekan secara permanen untuk menggunakan RSA, Anda harus memperbarui ke SHA2 atau menghapus entri.
• Masalah yang diatasi dengan tautan relatif tidak berfungsi dalam file markdown.
• Memperbaiki bug dengan navigasi komentar pada halaman penerapan.
• Memperbaiki bug di mana identitas Pemilik Analisis ditampilkan sebagai Identitas Tidak Aktif.
• Memperbaiki bug perulangan tak terbatas pada CronScheduleJobExtension.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 6: 13 Juni 2023

Kami telah merilis patch untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut.

• CVE-2023-21565: Kerentanan Spoofing Server Azure DevOps.
• CVE-2023-21569: Kerentanan Spoofing Server Azure DevOps.
• Memperbaiki bug yang mengganggu paket pendorongan saat meningkatkan dari 2018 atau yang lebih lama.
• Memperbaiki bug di mana melepaskan atau melampirkan koleksi gagal melaporkan kesalahan berikut: 'TF246018: Operasi database melebihi batas waktu habis dan telah dibatalkan.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 5: 14 Februari 2023

Kami telah merilis patch untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut.

• CVE-2023-21553: Kerentanan Eksekusi Kode Jarak Jauh Azure DevOps Server
• Memperbaiki masalah aksesibilitas shelveset melalui UI web
• Pelanggan perlu memulai ulang layanan tfsjobagent dan kumpulan aplikasi Azure DevOps Server setelah memperbarui pengaturan terkait SMTP di Konsol Manajemen Server Azure DevOps.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 4: 13 Desember 2022

Kami telah merilis patch untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut.

• Memperbaiki tampilan karakter khusus di IdentityPicker.

• Data pengujian tidak dihapus, menyebabkan database bertambah. Dengan perbaikan ini, kami memperbarui retensi build untuk mencegah pembuatan data pengujian yatim piatu baru.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 3: 18 Oktober 2022

Kami telah merilis patch untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut.

• Atasi masalah dengan identitas AD yang baru ditambahkan tidak muncul di pemilih identitas dialog keamanan.
• Perbaiki masalah dengan filter Diminta oleh Anggota Grup di pengaturan web hook.
• Memperbaiki kesalahan build check-in Gated saat pengaturan Organisasi untuk alur memiliki cakupan otorisasi pekerjaan yang dikonfigurasi sebagai Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis.
• Perbaiki pengambilan token akses dari Azure saat membuat koneksi layanan di balik proksi yang diautentikasi.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 2: 9 Agustus 2022

Kami telah merilis patch untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut.

• Perbaiki kesalahan nilai identitas saat menetapkan item kerja ke identitas yang muncul di domain yang berbeda.

Tanggal Rilis Azure DevOps Server 2020 Update 1.2 Patch 1: 12 Juli 2022

Kami telah merilis patch untuk Azure DevOps Server 2020 Update 1.2 yang mencakup perbaikan untuk hal berikut.

• Dalam API Uji Eksekusi, token lanjutan yang dikembalikan lebih besar dari nilai "maxLastUpdatedDate" yang ditentukan.

Azure DevOps Server 2020 Update 1.2 Tanggal Rilis: 17 Mei 2022

Azure DevOps Server 2020 Update 1.2 adalah serangkaian perbaikan bug. Anda dapat langsung menginstal Azure DevOps Server 2020 Update 1.2 atau meningkatkan dari Azure DevOps Server 2020 atau Team Foundation Server 2013 atau yang lebih baru.

Catatan

Alat Migrasi Data akan tersedia untuk Azure DevOps Server 2020 Update 1.2 sekitar tiga minggu setelah rilis ini. Anda dapat melihat daftar versi yang saat ini didukung untuk pengimporan di sini.

Rilis ini mencakup perbaikan untuk hal berikut:

• Azure DevOps Server 2020.1.2 menonaktifkan model retensi baru (diperkenalkan pada Azure DevOps Server 2020), untuk mencegah hilangnya eksekusi alur (build). Artinya sistem akan:

  • Membuat sewa untuk 3 build terbaru yang dihasilkan saat menjalankan Server 2020
  • Untuk alur YAML dan alur Classic tanpa kebijakan retensi per alur, build akan dipertahankan sesuai dengan pengaturan retensi maksimum tingkat koleksi
  • Untuk alur Classic dengan kebijakan retensi per alur kustom, build akan dipertahankan sesuai dengan kebijakan penyimpanan khusus alur
  • Build dengan sewa tidak diperhitungkan dalam Minimum untuk mempertahankan pengaturan

• Tautan komentar changeset dan shelveset tidak dialihkan dengan benar. Ketika komentar ditambahkan ke file dalam changeset atau shelveset, memilih komentar tersebut tidak mengalihkan ke tempat yang benar dalam tampilan file.

• Tidak dapat melewati antrean build menggunakan tombol "Jalankan berikutnya". Sebelumnya, tombol "Jalankan berikutnya" diaktifkan hanya untuk administrator kumpulan proyek.

• Cabut semua token akses pribadi setelah akun Active Directory pengguna dinonaktifkan.

Tanggal Rilis Patch 4 Azure DevOps Server 2020.1.1: 26 Januari 2022

Kami telah merilis patch untuk Azure DevOps Server 2020.1.1 yang mencakup perbaikan untuk hal berikut.

• Pemberitahuan email tidak dikirim saat menggunakan kontrol @mention di item kerja.
• Alamat email pilihan tidak diperbarui di profil pengguna. Hal ini mengakibatkan email dikirim ke alamat email sebelumnya.
• Header tidak ditampilkan di halaman Ringkasan Proyek. Header ditampilkan selama beberapa milidetik lalu menghilang.
• Peningkatan sinkronisasi pengguna Active Directory.
• Mengatasi kerentanan Elasticsearch dengan menghapus kelas jndilookup dari biner log4j.

Langkah-langkah penginstalan

1. Tingkatkan server dengan Patch 4.
2. Periksa nilai registri di HKLM:\Software\Elasticsearch\Version. Jika nilai registri tidak ada, tambahkan nilai string dan atur Versi ke 5.4.1 (Nama = Versi, Nilai = 5.4.1).
3. Jalankan perintah pembaruan PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update seperti yang disediakan dalam file readme. Ini mungkin mengembalikan peringatan seperti: Tidak dapat tersambung ke server jarak jauh. Jangan tutup jendela, karena pembaruan sedang melakukan percobaan ulang hingga selesai.

Catatan

Jika Azure DevOps Server dan Elasticsearch diinstal pada komputer yang berbeda, ikuti langkah-langkah yang diuraikan di bawah ini.

1. Tingkatkan server dengan Patch 4.
2. Periksa nilai registri di HKLM:\Software\Elasticsearch\Version. Jika nilai registri tidak ada, tambahkan nilai string dan atur Versi ke 5.4.1 (Nama = Versi, Nilai = 5.4.1).
3. Salin konten folder bernama zip, yang terletak di C:\Program Files\{TFS Version Folder}\Search\zip ke folder file jarak jauh Elasticsearch.
4. Jalankan Configure-TFSSearch.ps1 -Operation update di komputer server Elasticsearch.

Hash SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Tanggal Rilis Patch 3 Azure DevOps Server 2020.1.1: 15 Desember 2021

Patch 3 untuk Azure DevOps Server 2020.1.1 mencakup perbaikan untuk hal berikut.

• Memperbaiki makro item kerja untuk kueri dengan "Berisi Kata". Sebelumnya, kueri mengembalikan hasil yang salah untuk nilai yang berisi pemisah baris.
• Meningkatkan batas untuk panjang karakter versi paket Maven.
• Masalah pelokalan untuk status tata letak item kerja kustom.
• Masalah pelokalan dalam templat pemberitahuan email.
• Masalah dengan evaluasi aturan NOTSAMEAS ketika beberapa aturan NOTSAMEAS ditentukan untuk suatu bidang.

Tanggal Rilis Patch 2 Azure DevOps Server 2020.1.1: 26 Oktober 2021

Patch 2 untuk Azure DevOps Server 2020.1.1 mencakup perbaikan untuk hal berikut.

• Sebelumnya, Azure DevOps Server hanya dapat membuat koneksi ke GitHub Enterprise Server. Dengan patch ini, administrator proyek dapat membuat koneksi antara Azure DevOps Server dan repositori di GitHub.com. Anda dapat menemukan pengaturan ini di halaman koneksi GitHub di bawah Pengaturan Proyek.
• Mengatasi masalah dengan widget Dokumen Pengujian. Laporan eksekusi pengujian menunjukkan pengguna yang salah pada hasil.
• Perbaiki masalah dengan halaman ringkasan Gambaran Umum Proyek yang gagal dimuat.
• Memperbaiki masalah dengan email yang tidak terkirim untuk mengonfirmasi peningkatan produk.

Tanggal Rilis Patch 1 Azure DevOps Server 2020.1.1: 14 September 2021

Patch 1 untuk Azure DevOps Server 2020.1.1 mencakup perbaikan untuk hal berikut.

• Memperbaiki kegagalan pengunduhan/pengunggahan Artefak.
• Mengatasi masalah dengan data Hasil Pengujian yang tidak konsisten.

Tanggal Rilis Pembaruan 1.1 Azure DevOps Server 2020: 17 Agustus 2021

Pembaruan 1.1 Azure DevOps Server 2020 adalah serangkaian perbaikan bug. Anda dapat langsung menginstal Pembaruan 1.1 Azure DevOps Server 2020 atau meningkatkan dari Azure DevOps Server 2020 atau Team Foundation Server 2013 atau yang lebih baru.

Catatan

Alat Migrasi Data akan tersedia untuk Pembaruan 1.1 Azure DevOps Server 2020 sekitar tiga minggu setelah rilis ini. Anda dapat melihat daftar versi yang saat ini didukung untuk pengimporan di sini.

Rilis ini mencakup perbaikan untuk bug berikut:

Azure Boards

• Hyperlink "Tampilkan item kerja" di email pemberitahuan tidak menggunakan URL publik.

Azure Repos

• Memperbaiki tampilan kotak centang pewarisan jenis gabungan terbatas untuk mengaktifkan modifikasi jenis gabungan batas setelah mengatur kebijakan lintas repositori.

Azure Pipelines

• Saat mengubah pengaturan untuk Pembaruan Agen, pengaturan tidak menyebar ke tingkat aplikasi lain di lingkungan.

Umum

• Memperbaiki ejaan di wizard konfigurasi server.
• Peningkatan ukuran paket ekstensi dan memungkinkan Anda untuk mengubah ukuran di registri.

Azure Test Plans

• Tidak dapat menavigasi kembali ke hasil pengujian setelah Anda menekan kembali dari riwayat ke halaman ringkasan.

---

Tanggal Rilis Patch 2 Azure DevOps Server 2020.1: 10 Agustus 2021

Kami telah merilis patch untuk Azure DevOps Server 2020.1 yang memperbaiki hal berikut.

• Memperbaiki kesalahan UI definisi build.
• Mengubah riwayat penjelajahan untuk menampilkan file, bukan repositori akar.

Tanggal Rilis Patch 1 Azure DevOps Server 2020.1: 15 Juni 2021

Kami telah merilis patch untuk Azure DevOps Server 2020.1 yang memperbaiki hal berikut.

• Mengamankan cookie yang digunakan dalam alur otorisasi yang menegaskan SameSite=None.

• Mengatasi masalah dengan SDK Pemberitahuan. Sebelumnya, langganan pemberitahuan yang menggunakan filter Jalur Area tidak diurai dengan benar.

Tanggal Rilis RTW Azure DevOps Server 2020.1: 25 Mei 2021

Ringkasan Apa yang Baru di RTW Azure DevOps Server 2020.1

RTW Azure DevOps Server 2020.1 adalah serangkaian perbaikan bug. Ini mencakup semua fitur di RC2 Azure DevOps Server 2020.1 yang dirilis sebelumnya. RTW Azure DevOps Server 2020.1 adalah serangkaian perbaikan bug. Anda dapat langsung menginstal Azure DevOps Server 2020.1 atau meningkatkan dari Azure DevOps Server 2020, 2019 atau Team Foundation Server 2015 atau yang lebih baru.

Catatan

Alat Migrasi Data akan tersedia untuk Pembaruan 1 Azure DevOps Server 2020 sekitar tiga minggu setelah rilis ini. Anda dapat melihat daftar versi yang saat ini didukung untuk pengimporan di sini.

Tanggal Rilis RC2 Azure DevOps Server 2020.1: 13 April 2021

Ringkasan Apa yang Baru di RC2 Azure DevOps Server 2020.1

RC2 Azure DevOps Server 2020.1 adalah serangkaian perbaikan bug. Ini mencakup semua fitur di RC1 Azure DevOps Server 2020.1 yang dirilis sebelumnya.

Tanggal Rilis RC1 Azure DevOps Server 2020.1: 23 Maret 2021

Ringkasan Apa yang Baru di RC1 Azure DevOps Server 2020.1

RC1 Azure DevOps Server 2020.1 memperkenalkan banyak fitur baru. Beberapa sorotannya meliputi:

• Aturan pembatasan transisi status di Boards
• Pemangku kepentingan sekarang dapat memindahkan item kerja di seluruh kolom papan
• Meningkatkan keamanan rilis dengan membatasi cakupan token akses
• Pengalaman permintaan pull yang ditingkatkan
• Pemicu multi-repositori di Alur

Anda juga dapat langsung membuka bagian individual dan melihat semua fitur baru untuk setiap layanan:

• Papan
• Repositori
• Pipelines
• Artefak

---

Boards

Aturan pembatasan transisi status

Kami terus menutup celah paritas fitur antara XML yang dihosting dan model proses yang diwarisi. Aturan tipe item kerja baru ini memungkinkan Anda membatasi item kerja agar tidak dipindahkan dari satu status ke status lainnya. Misalnya, Anda dapat membatasi Bug dari Baru ke Diselesaikan. Sebagai gantinya, mereka harus beralih dari Baru –> Aktif -> Diselesaikan

Anda juga dapat membuat aturan untuk membatasi transisi status berdasarkan keanggotaan grup. Misalnya, hanya pengguna di grup "Pemberi Izin" yang dapat memindahkan cerita pengguna dari Baru -> Disetujui.

Salin item kerja untuk menyalin turunan

Salah satu fitur yang paling banyak diminta untuk Azure Boards adalah kemampuan untuk menyalin item kerja yang juga menyalin item kerja turunan. Kami menambahkan opsi baru untuk "Sertakan item kerja turunan" ke dialog salin item kerja. Jika dipilih, opsi ini akan menyalin item kerja dan menyalin semua item kerja turunan (hingga 100).

Aturan yang ditingkatkan untuk bidang yang diaktifkan dan diselesaikan

Hingga saat ini, aturan untuk Diaktifkan Oleh, Tanggal Diaktifkan, Diselesaikan Oleh, dan Tanggal Diselesaikan masih menjadi misteri. Aturan hanya ditetapkan untuk tipe item kerja sistem dan khusus untuk nilai status "Aktif" dan "Diselesaikan". Kami telah mengubah logika sehingga aturan ini tidak lagi untuk status tertentu. Sebaliknya, aturan dipicu oleh kategori (kategori status) tempat status berada. Misalnya, Anda memiliki status kustom "Memerlukan Pengujian" dalam kategori Diselesaikan. Saat item kerja berubah dari "Aktif" menjadi "Memerlukan Pengujian", aturan Diselesaikan Oleh dan Tanggal Diselesaikan dipicu.

Ini memungkinkan pelanggan untuk membuat nilai status kustom apa pun dan tetap menghasilkan bidang Diaktifkan Oleh, Tanggal Diaktifkan, Diselesaikan Oleh, dan Tanggal Diselesaikan, tanpa perlu menggunakan aturan kustom.

Pemangku kepentingan dapat memindahkan item kerja di seluruh kolom papan

Pemangku kepentingan selalu dapat mengubah status item kerja. Tetapi ketika mereka masuk ke papan Kanban, mereka tidak dapat memindahkan item kerja dari satu kolom ke kolom lainnya. Sebaliknya, Pemangku Kepentingan harus membuka setiap item kerja, satu per satu, dan memperbarui nilai status. Ini telah lama menjadi masalah rumit bagi pelanggan, dan dengan senang hati kami mengumumkan bahwa sekarang Anda dapat memindahkan item kerja di seluruh kolom papan.

Tipe item kerja sistem pada backlog dan papan

Sekarang Anda dapat menambahkan tipe item kerja sistem ke tingkat backlog pilihan. Secara historis tipe item kerja ini hanya tersedia dari kueri.

Proses	Tipe Item Kerja
Agile	Masalah
Scrum	Halangan
CMMI	Permintaan Perubahan
	Masalah
	Tinjauan
	Risiko

Menambahkan tipe item kerja sistem ke tingkat backlog itu sederhana. Cukup masuk ke proses kustom Anda dan klik tab Tingkat Backlog. Pilih tingkat backlog pilihan Anda (contoh: Backlog Persyaratan) dan pilih opsi edit. Lalu tambahkan tipe item kerja.

Batas repositori aplikasi Azure Boards GitHub dinaikkan

Batas repositori untuk aplikasi Azure Boards di marketplace GitHub telah ditingkatkan dari 100 menjadi 250.

Sesuaikan status item kerja saat permintaan pull digabungkan

Tidak semua alur kerja sama. Beberapa pelanggan ingin menutup item kerja terkait mereka saat Permintaan Pull selesai. Pelanggan yang lain ingin mengatur item kerja ke status lain untuk divalidasi sebelum ditutup. Kita harus mengizinkan keduanya.

Kami memiliki fitur baru yang memungkinkan Anda mengatur item kerja ke status yang diinginkan saat permintaan pull digabungkan dan diselesaikan. Untuk melakukan ini, kami memindai deskripsi permintaan pull dan mencari nilai status diikuti dengan menggunakan #mention item kerja. Dalam contoh ini, kami mengatur dua cerita pengguna ke Diselesaikan dan menutup dua tugas.

Tautkan item kerja Anda ke build di proyek lain

Anda sekarang dapat dengan mudah melacak dependensi build di seluruh proyek hanya dengan menautkan item kerja ke Build, Ditemukan di build, atau Terintegrasi di build.

Mengedit deskripsi (teks bantuan) pada bidang sistem

Anda selalu dapat mengedit deskripsi bidang isian kustom. Namun untuk bidang sistem seperti prioritas, tingkat keparahan, dan aktivitas, deskripsi tidak dapat diedit. Ini adalah celah fitur antara XML yang Dihosting dan Diwarisi yang mencegah beberapa pelanggan bermigrasi ke model yang Diwarisi. Anda sekarang dapat mengedit deskripsi pada bidang sistem. Nilai yang diedit hanya akan memengaruhi bidang tersebut dalam proses dan untuk tipe item kerja tersebut. Ini memberi Anda fleksibilitas untuk memiliki deskripsi yang berbeda untuk bidang yang sama pada tipe item kerja yang berbeda.

Sesuaikan status item kerja saat permintaan pull digabungkan

Permintaan pull sering merujuk ke beberapa item kerja. Saat membuat atau memperbarui permintaan pull, Anda mungkin ingin menutup beberapa, menyelesaikan beberapa, dan membiarkan sisanya tetap terbuka. Anda sekarang dapat menggunakan komentar seperti yang ditunjukkan pada gambar di bawah untuk mencapai hal itu. Lihat dokumentasi untuk detail selengkapnya.

Bidang induk pada papan tugas

Karena permintaan populer, Anda sekarang dapat menambahkan bidang Induk ke kartu turunan dan induk di Papan Tugas.

Menghapus aturan "Ditetapkan Ke" pada tipe item kerja Bug

Ada beberapa aturan sistem tersembunyi di semua tipe item kerja yang berbeda di Agile, Scrum, dan CMMI. Aturan ini telah ada selama lebih dari satu dekade dan umumnya bekerja dengan baik tanpa keluhan apa pun. Namun, ada beberapa aturan yang telah kehabisan sambutannya. Satu aturan secara khusus telah menyebabkan banyak masalah bagi pelanggan baru dan lama, dan kami telah memutuskan sudah waktunya untuk menghapusnya. Aturan ini ada pada tipe item kerja Bug dalam proses Agile.

"Atur nilai yang Ditetapkan ke Dibuat Oleh saat status diubah menjadi Diselesaikan"

Kami menerima banyak umpan balik Anda tentang aturan ini. Sebagai tanggapan, kami melanjutkan dan menghapus aturan ini dari tipe item kerja Bug dalam proses Agile. Perubahan ini akan memengaruhi setiap proyek yang menggunakan Agile yang diwarisi atau proses Agile yang diwarisi khusus. Bagi pelanggan yang menyukai dan bergantung pada aturan saat ini, lihat posting blog kami tentang langkah-langkah yang dapat Anda ambil untuk menambahkan kembali aturan dalam menggunakan aturan kustom.

Item yang dihapus di halaman Item Kerja

Halaman Item Kerja adalah tempat yang tepat untuk dengan cepat menemukan item yang Anda buat atau yang ditetapkan untuk Anda, di antara yang lain. Halaman ini menyediakan beberapa pivot dan filter yang dipersonalisasi. Salah satu keluhan utama untuk pivot "Ditetapkan untuk saya" adalah bahwa pivot menampilkan item kerja yang Dihapus (yaitu, item kerja dalam status Dihapus). Dan kami setuju! Item yang dihapus adalah pekerjaan yang tidak lagi bernilai dan karenanya telah dihapus dari backlog, jadi menyertakannya dalam tampilan ini tidak membantu.

Anda sekarang dapat menyembunyikan semua item yang Dihapus dari pivot Ditetapkan untuk saya di halaman Item Kerja.

Repositori

Preferensi nama cabang default

Azure Repos sekarang menawarkan nama cabang default yang dapat disesuaikan untuk Git. Dalam pengaturan repositori, Anda dapat memilih nama cabang resmi apa pun untuk digunakan saat repositori diinisialisasi. Azure Repos selalu mendukung perubahan nama cabang default untuk repositori yang ada.

Untuk informasi selengkapnya, lihat Mengelola cabang dan Mengubah cabang default.

Pengaturan tingkat organisasi untuk cabang default

Sekarang ada pengaturan tingkat koleksi untuk nama cabang awal pilihan Anda untuk repositori baru. Jika sebuah proyek belum memilih nama cabang awal, maka pengaturan tingkat organisasi ini akan digunakan. Jika Anda tidak menentukan nama cabang awal dalam pengaturan organisasi atau pengaturan proyek, maka repositori baru akan menggunakan default yang ditentukan Azure DevOps.

Tambahkan cakupan autentikasi baru untuk memberikan komentar permintaan pull

Rilis ini menambahkan cakupan OAuth baru untuk membaca/menulis komentar permintaan pull. Jika memiliki bot atau otomatisasi yang hanya perlu berinteraksi dengan komentar, Anda dapat memberinya PAT hanya dengan cakupan ini. Proses ini mengurangi radius ledakan jika otomatisasi memiliki bug atau jika token disusupi.

Peningkatan pengalaman Permintaan Pull

Pengalaman permintaan pull baru telah ditingkatkan dengan hal berikut:

• Jadikan pemeriksaan opsional lebih terlihat

Pelanggan menggunakan pemeriksaan opsional untuk menarik perhatian pengembang terhadap potensi masalah. Dalam pengalaman sebelumnya, terlihat jelas ketika pemeriksaan ini gagal. Namun, itu tidak terjadi dalam pengalaman pratinjau. Tanda centang hijau besar pada pemeriksaan yang diperlukan menutupi kegagalan dalam pemeriksaan opsional. Pengguna hanya dapat menemukan bahwa pemeriksaan opsional gagal dengan membuka panel pemeriksaan. Pengembang tidak sering melakukan itu ketika tidak ada indikasi masalah. Dalam penyebaran ini, kami membuat status pemeriksaan opsional lebih terlihat di ringkasan.

• Ctrl-klik pada item menu

Menu tab pada permintaan pull tidak mendukung Ctrl-klik. Pengguna sering membuka tab browser baru saat mereka meninjau permintaan pull. Hal ini telah diperbaiki.

• Lokasi anotasi [+]

Daftar pohon file dalam permintaan pull menunjukkan anotasi [+] untuk membantu pembuat dan peninjau mengidentifikasi file baru. Karena anotasi berada setelah elipsis, anotasi sering kali tidak terlihat untuk nama file yang lebih panjang.

• Dropdown pembaruan permintaan pull mendapatkan kembali informasi waktu

Menu dropdown untuk memilih pembaruan dan membandingkan file dalam permintaan pull kehilangan elemen penting dalam pengalaman pratinjau. Ini tidak menunjukkan kapan pembaruan itu dilakukan. Hal ini telah diperbaiki.

• **Peningkatan tata letak filter komentar **

Saat memfilter komentar di halaman ringkasan permintaan pull, drop-down ada di sebelah kanan, tetapi teksnya rata kiri. Hal ini telah diperbaiki.

• Navigasi ke penerapan induk

Di bawah halaman Penerapan, Anda dapat membandingkan perubahan yang dibuat pada penerapan tertentu dengan penerapan induknya. Namun, Anda mungkin ingin menavigasi ke penerapan induk dan lebih memahami bagaimana penerapan itu berbeda dari induknya sendiri. Ini sering diperlukan ketika Anda ingin memahami semua perubahan dalam rilis. Kami menambahkan kartu induk ke penerapan untuk membantu Anda mencapai hal ini.

• Lebih banyak ruang untuk folder dan file dengan nama panjang di tab file permintaan pull

Folder dan file dengan nama panjang terpotong karena kurangnya penspasian horizontal di pohon file. Kami memulihkan beberapa ruang tambahan di pohon dengan memodifikasi indentasi pohon agar sesuai dengan node akar dan dengan menyembunyikan tombol elipsis dari halaman kecuali saat mengarahkan kursor.

Gambar pohon file baru:

Gambar pohon file saat mengarahkan kursor ke direktori:

• Pertahankan posisi gulir saat mengubah ukuran panel yang berbeda di tab file permintaan pull

Saat mengubah ukuran panel yang berbeda berdampingan di tab file permintaan pull, lokasi gulir pengguna akan hilang. Masalah ini telah diperbaiki; lokasi gulir pengguna sekarang dipertahankan pada pengubahan ukuran panel yang berbeda.

• Cari penerapan di perangkat seluler

Saat melihat halaman Penerapan di perangkat seluler, kotak pencarian tidak ada di pengalaman baru. Akibatnya, sulit bagi Anda untuk menemukan penerapan dengan hash-nya dan membukanya. Hal ini telah diperbaiki sekarang.

• Peningkatan penggunaan ruang untuk file permintaan pull baru tampilan seluler yang berbeda

Kami memperbarui halaman ini untuk memanfaatkan ruang dengan lebih baik sehingga pengguna dapat melihat lebih banyak file dalam tampilan seluler daripada 40% layar diambil oleh header.

• Gambar yang ditingkatkan dalam tampilan ringkasan permintaan pull

Gambar yang diedit dalam permintaan pull tidak ditampilkan dalam tampilan ringkasan permintaan pull, tetapi ditampilkan dengan benar dalam tampilan file permintaan pull. Masalah tersebut telah diselesaikan.

• Pengalaman cabang yang ditingkatkan saat membuat permintaan pull baru

Sebelum pembaruan ini, pengalaman ini tidak ideal karena akan membandingkan perubahan dengan cabang default repositori, bukan cabang perbandingan.

Pipelines

Platform agen tambahan: ARM64

Kami menambahkan Linux/ARM64 ke daftar platform yang didukung untuk agen Azure Pipelines. Meskipun perubahan kodenya minimal, banyak pekerjaan di balik layar yang harus diselesaikan terlebih dahulu, dan kami sangat senang untuk mengumumkan rilisnya!

Dukungan filter tag untuk sumber daya alur

Kami sekarang telah menambahkan 'tag' di alur YAML. Anda dapat menggunakan tag untuk mengatur alur CI agar berjalan atau kapan harus memicu secara otomatis.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

Cuplikan di atas menunjukkan bahwa tag dapat digunakan untuk menentukan versi default dari alur CI (integrasi berkelanjutan) yang akan dijalankan ketika eksekusi alur CD (penyebaran berkelanjutan) tidak dipicu oleh beberapa sumber/sumber daya lain atau pemicu eksekusi terjadwal.

Misalnya, jika Anda memiliki pemicu terjadwal yang ditetapkan untuk alur CD yang hanya ingin dijalankan jika CI Anda memiliki tag produksi, tag di bagian pemicu memastikan bahwa alur CD hanya dipicu jika kondisi pemberian tag dipenuhi oleh peristiwa penyelesaian CI.

Kontrol tugas mana yang diizinkan dalam alur

Sekarang Anda dapat menonaktifkan tugas Marketplace. Beberapa dari Anda mungkin mengizinkan ekstensi Marketplace, tetapi bukan tugas Pipelines yang mereka bawa. Untuk kontrol yang lebih besar, kami juga mengizinkan Anda menonaktifkan semua tugas yang ada di dalam kotak secara mandiri (kecuali selesai, yang merupakan tindakan khusus). Dengan kedua pengaturan ini diaktifkan, satu-satunya tugas yang diizinkan untuk dijalankan dalam alur adalah tugas yang diunggah menggunakan tfx. Kunjungi https://dev.azure.com/<your_org>/_settings/pipelinessettings dan cari bagian yang disebut "Pembatasan tugas" untuk memulai.

Kebijakan kunci penyebaran eksklusif

Dengan pembaruan ini, Anda dapat memastikan bahwa hanya satu eksekusi yang disebarkan ke lingkungan dalam satu waktu. Dengan memilih centang "Kunci eksklusif" pada lingkungan, hanya satu eksekusi yang akan dilanjutkan. Eksekusi selanjutnya yang ingin disebarkan ke lingkungan tersebut akan dijeda. Setelah eksekusi dengan kunci eksklusif selesai, eksekusi terbaru akan dilanjutkan. Setiap eksekusi perantara akan dibatalkan.

Filter tahapan untuk pemicu sumber daya alur

Kami menambahkan dukungan untuk 'tahapan' sebagai filter untuk sumber daya alur di YAML. Dengan filter ini, Anda tidak perlu menunggu seluruh alur CI selesai untuk memicu alur CD Anda. Anda sekarang dapat memilih untuk memicu alur CD setelah menyelesaikan tahap tertentu dalam alur CI Anda.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Saat tahapan yang disediakan dalam filter pemicu berhasil diselesaikan di alur CI Anda, eksekusi baru secara otomatis dipicu untuk alur CD Anda.

Pemicu berbasis webhook umum untuk alur YAML

Saat ini, kami memiliki berbagai sumber daya (seperti alur, kontainer, build, dan paket) yang dapat digunakan untuk menggunakan artefak dan mengaktifkan pemicu otomatis. Namun, hingga saat ini, Anda tidak dapat mengotomatiskan proses penyebaran berdasarkan peristiwa atau layanan eksternal lainnya. Dalam rilis ini, kami memperkenalkan dukungan pemicu webhook di alur YAML untuk memungkinkan integrasi otomatisasi alur dengan layanan eksternal apa pun. Anda dapat berlangganan peristiwa eksternal apa pun melalui webhook-nya (Github, Github Enterprise, Nexus, Aritfactory, dll.) dan memicu alur Anda.

Berikut adalah langkah-langkah untuk mengonfigurasi pemicu webhook:

1. Siapkan webhook di layanan eksternal Anda. Saat membuat webhook, Anda harus memberikan info berikut:

   • Url Permintaan - "https://dev.azure.com/<ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
   • Rahasia - Ini opsional. Jika Anda perlu mengamankan payload JSON Anda, berikan nilai Rahasia

2. Buat koneksi layanan "Webhook Masuk" baru. Ini adalah Tipe Koneksi Layanan yang baru diperkenalkan yang memungkinkan Anda menentukan tiga informasi penting:

   • Nama Webhook: Nama webhook harus cocok dengan webhook yang dibuat di layanan eksternal Anda.
   • Header HTTP - Nama header HTTP dalam permintaan yang berisi nilai hash payload untuk verifikasi permintaan. Misalnya, dalam kasus GitHub, header permintaan akan menjadi "X-Hub-Signature"
   • Rahasia - Rahasia digunakan untuk mengurai hash payload yang digunakan untuk verifikasi permintaan masuk (ini opsional). Jika telah menggunakan rahasia dalam membuat webhook, Anda harus memberikan kunci rahasia yang sama

   

3. Jenis sumber daya baru yang disebut webhooks diperkenalkan di alur YAML. Untuk berlangganan peristiwa webhook, Anda perlu menentukan sumber daya webhook di alur Anda dan mengarahkannya ke koneksi layanan webhook Masuk. Anda juga dapat menentukan filter tambahan pada sumber daya webhook berdasarkan data payload JSON untuk menyesuaikan pemicu lebih lanjut untuk setiap alur, dan Anda dapat menggunakan data payload dalam bentuk variabel dalam pekerjaan.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. Setiap kali peristiwa webhook diterima oleh koneksi layanan Webhook Masuk, eksekusi baru akan dipicu untuk semua alur yang berlangganan peristiwa webhook.

Dukungan dan ketertelusuran masalah pemicu sumber daya YAML

Ini bisa membingungkan ketika pemicu alur gagal dijalankan seperti yang Anda harapkan. Untuk membantu lebih memahami hal ini, kami telah menambahkan item menu baru di halaman definisi alur yang disebut 'Masalah Pemicu' di mana informasi muncul mengenai mengapa pemicu tidak dijalankan.

Pemicu sumber daya dapat gagal dijalankan karena dua alasan.

1. Jika sumber koneksi layanan yang disediakan tidak valid, atau jika ada galat sintaksis di pemicu, pemicu tidak akan dikonfigurasi sama sekali. Ini muncul sebagai kesalahan.

2. Jika kondisi pemicu tidak cocok, pemicu tidak akan dijalankan. Setiap kali ini terjadi, peringatan akan muncul sehingga Anda dapat memahami mengapa kondisi tidak cocok.

   

Pemicu multi-repositori

Anda dapat menentukan beberapa repositori dalam satu file YAML dan menyebabkan alur dipicu oleh pembaruan ke salah satu repositori. Fitur ini berguna, misalnya, dalam skenario berikut:

• Anda menggunakan alat atau pustaka dari repositori yang berbeda. Anda ingin menjalankan pengujian untuk aplikasi Anda setiap kali alat atau pustaka diperbarui.
• Anda menyimpan file YAML Anda di repositori terpisah dari kode aplikasi. Anda ingin memicu alur setiap kali pembaruan didorong ke repositori aplikasi.

Dengan pembaruan ini, pemicu multi-repositori hanya akan berfungsi untuk repositori Git di Azure Repos. Pemicu tidak berfungsi untuk sumber daya repositori GitHub atau BitBucket.

Berikut adalah contoh yang menunjukkan cara menentukan beberapa sumber daya repositori dalam alur dan cara mengonfigurasi pemicu pada semuanya.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Alur dalam contoh ini akan dipicu jika ada pembaruan untuk:

• cabang main di repositori self yang berisi file YAML
• cabang main atau release di repositori tools

Untuk informasi lebih lanjut, lihat Beberapa repositori di alur Anda.

Unggahan log agen ditingkatkan

Saat agen berhenti berkomunikasi dengan server Azure Pipelines, pekerjaan yang dijalankannya akan ditinggalkan. Jika kebetulan melihat log konsol streaming, Anda mungkin mendapatkan beberapa petunjuk tentang apa yang dilakukan agen sebelum berhenti merespons. Tetapi jika tidak, atau jika Anda me-refresh halaman, log konsol tersebut hilang. Dengan rilis ini, jika agen berhenti merespons sebelum mengirimkan log lengkapnya, kami akan menyimpan log konsol sebagai hal terbaik berikutnya. Log konsol dibatasi hingga 1000 karakter per baris dan terkadang tidak lengkap, tetapi jauh lebih membantu daripada tidak menunjukkan apa-apa! Memeriksa log ini dapat membantu Anda memecahkan masalah alur Anda sendiri, dan itu pasti akan membantu teknisi dukungan kami ketika mereka membantu pemecahan masalah.

Secara opsional, pasang volume kontainer baca-saja

Saat Anda menjalankan pekerjaan kontainer di Azure Pipelines, beberapa volume yang berisi ruang kerja, tugas, dan materi lainnya dipetakan sebagai volume. Volume ini default untuk akses baca/tulis. Untuk meningkatkan keamanan, Anda dapat memasang volume baca-saja dengan mengubah spesifikasi kontainer di YAML. Setiap kunci di bawah mountReadOnly dapat diatur ke true untuk baca-saja (defaultnya adalah false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Kontrol detail atas mulai/berhenti kontainer

Secara umum, sebaiknya Anda mengizinkan Azure Pipelines mengelola siklus hidup kontainer pekerjaan dan layanan Anda. Namun, dalam beberapa skenario yang tidak umum, Anda mungkin ingin memulai dan menghentikannya sendiri. Dengan rilis ini, kami telah membangun kemampuan tersebut ke dalam tugas Docker.

Berikut adalah contoh alur yang menggunakan kemampuan baru:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Selain itu, kami menyertakan daftar kontainer dalam variabel alur, Agent.ContainerMapping. Anda dapat menggunakan ini jika ingin memeriksa daftar kontainer dalam skrip, misalnya. Ini berisi objek JSON string yang memetakan nama sumber daya ("penyusun" dari contoh di atas) ke ID kontainer yang dikelola agen.

Buka zip bundel tugas untuk setiap langkah

Saat agen menjalankan pekerjaan, pertama-tama agen mengunduh semua bundel tugas yang diperlukan oleh langkah-langkah pekerjaan. Biasanya, untuk performa, agen membuka zip tugas sekali per pekerjaan bahkan jika tugas digunakan dalam beberapa langkah. Jika memiliki kekhawatiran tentang kode tidak tepercaya yang mengubah konten yang tidak di-zip, Anda dapat menukar sedikit performa dengan meminta agen membuka zip tugas pada setiap penggunaan. Untuk mengaktifkan mode ini, teruskan --alwaysextracttask saat mengonfigurasi agen.

Meningkatkan keamanan rilis dengan membatasi cakupan token akses

Berdasarkan inisiatif kami untuk meningkatkan pengaturan keamanan untuk Azure Pipelines, kami sekarang mendukung pembatasan cakupan token akses untuk rilis.

Setiap pekerjaan yang berjalan dalam rilis mendapat token akses. Token akses digunakan oleh tugas dan skrip Anda untuk memanggil kembali ke Azure DevOps. Misalnya, kami menggunakan token akses untuk mendapatkan kode sumber, mengunduh artefak, mengunggah log, hasil pengujian, atau melakukan panggilan REST ke Azure DevOps. Token akses baru dibuat untuk setiap pekerjaan, dan akan kedaluwarsa setelah pekerjaan selesai.

Dengan pembaruan ini, kami meningkatkan keamanan alur dengan membatasi cakupan token akses dan memperluas hal yang sama ke rilis klasik.

Fitur ini akan diaktifkan secara default untuk proyek dan koleksi baru. Untuk koleksi yang sudah ada, Anda harus mengaktifkannya di Pengaturan > Pipelines > Pengaturan. > Batasi cakupan otorisasi pekerjaan untuk proyek saat ini untuk alur rilis. Pelajari selengkapnya di sini.

Peningkatan API pratinjau YAML

Anda sekarang dapat melihat pratinjau YAML lengkap alur tanpa menjalankannya. Selain itu, kami telah membuat URL baru khusus untuk kemampuan pratinjau. Sekarang Anda dapat POST ke https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview untuk mengambil badan YAML yang telah diselesaikan. API baru ini menggunakan parameter yang sama seperti mengantre untuk dijalankan, tetapi tidak lagi memerlukan izin "Build antrean".

Jalankan pekerjaan ini berikutnya

Pernahkah Anda memiliki perbaikan bug yang perlu disebarkan saat ini juga tetapi harus menunggu di belakang pekerjaan CI dan permintaan pull? Dengan rilis ini, kami sekarang mengizinkan Anda untuk meningkatkan prioritas antrean pekerjaan. Pengguna dengan izin "Kelola" di kumpulan - biasanya administrator kumpulan - akan melihat tombol "Jalankan berikutnya" baru di halaman detail pekerjaan. Mengeklik tombol akan mengatur pekerjaan untuk dijalankan sesegera mungkin. (Tentu saja Anda masih memerlukan paralelisme yang tersedia dan agen yang sesuai.)

Ekspresi templat diizinkan di blok resources YAML

Sebelumnya, ekspresi waktu kompilasi (${{ }}) tidak diizinkan di bagian resources file YAML Azure Pipelines. Dengan rilis ini, kami telah mencabut pembatasan ini untuk kontainer. Ini memungkinkan Anda untuk menggunakan konten parameter runtime di dalam sumber daya Anda, misalnya untuk memilih kontainer pada waktu antrean. Kami berencana untuk memperluas dukungan ini ke sumber daya lain dari waktu ke waktu.

Kontrol atas pembaruan tugas otomatis dari Marketplace

Saat menulis alur YAML, biasanya Anda hanya menentukan nomor versi utama dari tugas yang disertakan. Ini memungkinkan alur Anda untuk secara otomatis mengambil penambahan fitur terbaru dan perbaikan bug. Terkadang Anda mungkin perlu melakukan gulung balik ke rilis titik sebelumnya dari tugas, dan dengan pembaruan ini, kami menambahkan kemampuan bagi Anda untuk melakukannya. Anda sekarang dapat menentukan versi tugas major.minor.patch lengkap di alur YAML Anda.

Kami tidak menyarankan Anda melakukan ini secara teratur, dan menggunakannya hanya sebagai solusi sementara ketika Anda menemukan bahwa tugas yang lebih baru merusak alur. Selain itu, ini tidak akan menginstal versi tugas yang lebih lama dari Marketplace. Ini harus sudah ada di koleksi Anda atau alur Anda akan gagal.

Contoh:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Dukungan Node 10 dalam agen dan tugas

Karena Node 6 tidak lagi didukung, kami memigrasikan tugas untuk bekerja dengan Node 10. Untuk pembaruan ini, kami telah memigrasikan hampir 50% tugas dalam kotak ke Node 10. Agen sekarang dapat menjalankan tugas Node 6 dan Node 10. Dalam pembaruan di masa mendatang, kami akan sepenuhnya menghapus Node 6 dari agen. Untuk mempersiapkan penghapusan Node 6 dari agen, kami meminta Anda memperbarui ekstensi internal dan tugas kustom Anda untuk juga menggunakan Node 10 segera. Untuk menggunakan Node 10 untuk tugas Anda, di task.json Anda, di bawah execution, perbarui dari Node ke Node10.

Tingkatkan konversi YAML di perancang build klasik

Dengan rilis ini, kami memperkenalkan fitur "ekspor ke YAML" baru untuk alur build perancang. Simpan definisi alur Anda, lalu temukan "Ekspor ke YAML" pada menu ....

Fungsi ekspor baru menggantikan fungsi "Lihat sebagai YAML" yang sebelumnya ditemukan di perancang build klasik. Fungsi itu tidak lengkap karena hanya dapat memeriksa apa yang diketahui UI web tentang build, yang terkadang menyebabkan YAML yang dihasilkan salah. Fungsi ekspor baru memperhitungkan dengan tepat bagaimana alur akan diproses dan menghasilkan YAML dengan fidelitas penuh ke alur perancang.

Konversi platform web baru – Pengaturan repositori

Kami telah mengonversi dua halaman Pengaturan repositori menjadi satu pengalaman yang ditingkatkan ke platform web baru. Peningkatan ini tidak hanya membuat pengalaman lebih cepat dan lebih modern, tetapi halaman ini juga menyediakan satu titik masuk untuk semua kebijakan dari tingkat proyek hingga tingkat cabang.

Dengan pengalaman baru ini, navigasi untuk proyek dengan sejumlah besar repositori menjadi lebih mudah karena waktu muat yang lebih cepat dan filter pencarian tambahan. Anda juga dapat melihat kebijakan tingkat proyek dan daftar kebijakan lintas repositori di bawah tab Kebijakan.

Jika mengeklik repositori, Anda dapat melihat kebijakan dan izin yang ditetapkan di tingkat repositori. Di dalam tab kebijakan, Anda dapat melihat daftar setiap cabang tempat kebijakan ditetapkan. Sekarang, klik cabang untuk melihat semua kebijakan tanpa meninggalkan halaman Pengaturan repositori.

Sekarang, ketika kebijakan diwarisi dari cakupan yang lebih tinggi daripada yang sedang Anda kerjakan, kami menunjukkan kepada Anda dari mana kebijakan itu diwarisi di samping setiap kebijakan individu. Anda juga dapat menavigasi ke halaman tempat kebijakan tingkat yang lebih tinggi ditetapkan dengan mengeklik nama cakupan.

Halaman kebijakan itu sendiri juga telah ditingkatkan ke platform web baru dengan bagian yang dapat ditutup! Untuk meningkatkan pengalaman mencari kebijakan Validasi Build, Pemeriksaan Status, atau Peninjau Otomatis tertentu, kami telah menambahkan filter pencarian untuk setiap bagian.

Integrasi ServiceNow Change Management dengan alur YAML

Aplikasi Azure Pipelines untuk ServiceNow membantu Anda mengintegrasikan Azure Pipelines dan ServiceNow Change Management. Dengan pembaruan ini, kami melakukan perjalanan kami untuk membuat Azure Pipelines menyadari proses manajemen perubahan yang dikelola di ServiceNow lebih lanjut ke alur YAML.

Dengan mengonfigurasi pemeriksaan "ServiceNow Change Management" pada sumber daya, Anda sekarang dapat menjeda agar perubahan disetujui sebelum menyebarkan build ke sumber daya tersebut. Anda dapat secara otomatis membuat perubahan baru untuk tahapan atau menunggu permintaan perubahan yang ada.

Anda juga dapat menambahkan tugas UpdateServiceNowChangeRequest dalam pekerjaan server untuk memperbarui permintaan perubahan dengan status penyebaran, catatan, dll.

Artefak

Kemampuan untuk membuat umpan cakupan organisasi dari UI

Kami menghadirkan kembali kemampuan bagi pelanggan untuk membuat dan mengelola umpan cakupan koleksi melalui UI web untuk layanan lokal dan yang dihosting.

Anda sekarang dapat membuat umpan cakupan organisasi melalui UI, dengan membuka Artefak -> Buat Umpan dan memilih jenis umpan dalam Cakupan.

Meskipun kami merekomendasikan penggunaan umpan cakupan proyek yang selaras dengan penawaran Azure DevOps lainnya, Anda dapat kembali membuat, mengelola, dan menggunakan umpan cakupan koleksi melalui UI dan berbagai REST API. Lihat dokumentasi umpan kami untuk informasi lebih lanjut.

Versi Paket Pembaruan REST API sekarang tersedia untuk paket Maven

Sekarang Anda dapat menggunakan REST API "Versi Paket Pembaruan" Azure Artifacts untuk memperbarui versi paket Maven. Sebelumnya, Anda dapat menggunakan REST API untuk memperbarui versi paket untuk Paket NuGet, Maven, npm, dan Universal, tetapi bukan paket Maven.

Untuk memperbarui paket Maven, gunakan perintah HTTP PATCH sebagai berikut.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Anda dapat mengatur hal berikut:

Parameter URI

Nama	Di	Diperlukan	Jenis	Keterangan
artifactId	jalan	BENAR	string	ID artefak paket
umpan	jalan	BENAR	string	Nama atau ID umpan
groupid	jalan	BENAR	string	ID grup paket
collection	jalan	BENAR	string	Nama koleksi Azure DevOps
versi	jalan	BENAR	string	Versi paket
proyek	jalan		string	ID proyek atau nama proyek
versi-api	pertanyaan	BENAR	string	Versi API yang akan digunakan. Ini harus diatur ke '5.1-preview.1' untuk menggunakan versi api ini

Isi Permintaan

Nama	Jenis	Keterangan
views	JsonPatchOperation	Tampilan di mana versi paket akan ditambahkan

Untuk informasi lebih lanjut, lihat dokumentasi REST API saat diperbarui.

Tanggapan

Kami ingin mendengar pendapat Anda! Anda dapat melaporkan masalah atau memberikan ide dan melacaknya melalui Komunitas Pengembang dan mendapatkan saran tentang Stack Overflow.

---

Bagian Atas Halaman