Catatan Rilis Azure DevOps Server 2019

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 selengkapnya tentang penginstalan atau peningkatan 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 menggunakan TFS 2010 atau yang lebih lama, Anda perlu melakukan beberapa langkah sementara sebelum meningkatkan ke Azure DevOps Server 2019. Untuk mempelajari selengkapnya, 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 (build) baru yang berfungsi berdasarkan pengaturan tingkat proyek.

Azure DevOps Server 2020 menangani retensi build 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.

Azure DevOps Server 2019.0.1 Patch 16 Tanggal Rilis: 14 November 2023

Kami telah merilis patch untuk Azure DevOps Server 2019 Pembaruan 1.2 yang mencakup perbaikan untuk yang berikut ini.

• Memperluas daftar karakter yang diizinkan tugas PowerShell untuk Validasi parameter argumen aktifkan tugas shell.

Catatan

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

Menginstal patch

Penting

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

Mengonfigurasi TFX

1. Ikuti langkah-langkah dalam dokumentasi unggah 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 

Azure DevOps Server 2019.0.1 Patch 15 Tanggal Rilis: 12 September 2023

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

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

Penting

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

Menginstal patch

1. Unduh dan instal Azure DevOps Server 2019.0.1 Patch 15.

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

Azure DevOps Server 2019.0.1 Tanggal Rilis Patch 14: 8 Agustus 2022

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

• CVE-2023-36869: Azure DevOps Server Kerentanan Spoofing.

Azure DevOps Server 2019.0.1 Patch 13 Tanggal Rilis: 17 Mei 2022

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

• Cabut semua token akses pribadi setelah akun Direktori Aktif pengguna dinonaktifkan.

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 12: 26 Januari 2022

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

• Mengatasi kerentanan Elasticsearch dengan menghapus kelas jndilookup dari biner log4j.

Langkah-langkah penginstalan

1. Tingkatkan server dengan Patch 12.
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 komputer yang berbeda, ikuti langkah-langkah yang diuraikan di bawah ini.

1. Tingkatkan server dengan Patch 12.
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.

SHA-256 Hash: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 11: 10 Agustus 2021

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

• Perbaikan kesalahan antarmuka pengguna definisi build.

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 10: 13 April 2021

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

• CVE-2021-27067: Pengungkapan informasi

Untuk menerapkan Patch 10, Anda harus menginstal tugas AzureResourceGroupDeploymentV2.

AzureResourceGroupDeploymentV2 task installation

Catatan

Semua langkah yang disebutkan di bawah ini perlu dilakukan pada komputer Windows

Instal

1. Ekstrak paket AzureResourceGroupDeploymentV2.zip ke folder baru di komputer Anda. Misalnya: AzureResourceGroupDeploymentV2.

2. Unduh dan instal Node.js 14.15.1 dan npm (disertakan dengan unduhan Node.js) sesuai dengan komputer Anda.

3. Buka perintah dalam mode administrator dan jalankan perintah berikut untuk menginstal tfx-cli.

npm install -g tfx-cli

4. Buat token akses pribadi dengan hak istimewa Akses penuh dan salin token tersebut. Token akses Pribadi ini akan digunakan saat menjalankan perintah login tfx.

5. Jalankan hal berikut ini dari perintah. Saat diminta, masukkan URL Layanan dan token akses Pribadi.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Jalankan perintah berikut untuk mengunggah tugas di server. Gunakan jalur file .zip yang diekstrak dari langkah 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 9: 8 Desember 2020

Kami telah merilis patch untuk Azure DevOps Server 2019.0.1 yang memperbaiki hal berikut. Lihat posting blog untuk informasi selengkapnya.

• CVE-2020-1325: Kerentanan Spoofing Azure DevOps Server
• CVE-2020-17135: Kerentanan Spoofing Azure DevOps Server
• CVE-2020-17145: Kerentanan Spoofing Azure DevOps Server and Team Foundation Server
• Memperbaiki masalah dengan TFVC tidak memproses semua hasil

Penting

Harap baca instruksi lengkap yang diberikan di bawah ini sebelum menginstal patch ini.

Penginstalan patch umum

Jika memiliki Azure DevOps Server 2019.0.1, Anda harus menginstal Azure DevOps Server 2019.0.1 Patch 9.

Memverifikasi Penginstalan

• Opsi 1: Jalankan devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.exe adalah file yang diunduh dari tautan di atas. Output perintah ini akan mengatakan bahwa patch telah diinstal atau tidak diinstal.

• Opsi 2: Periksa versi file berikut: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 diinstal ke c:\Program Files\Azure DevOps Server 2019 secara default. Setelah menginstal Azure DevOps Server 2019.0.1 Patch 9, versinya adalah 17.143.30723.4 .

AzurePowerShellV4 task installation

Catatan

Semua langkah yang disebutkan di bawah ini perlu dilakukan pada komputer Windows

Prasyarat

1. Menginstal modul Azure PowerShell Az Azure Powershell di komputer agen privat Anda.

2. Membuat alur dengan tugas AzurePowerShellV4. Anda hanya akan melihat satu Gagal pada Kesalahan Standar dalam tugas tersebut.

Instal

1. Ekstrak paket AzurePowerShellV4.zip ke folder bernama AzurePowerShellV4.

2. Unduh dan instal Node.js 14.15.1 dan npm (disertakan dengan unduhan Node.js) sesuai dengan komputer Anda.

3. Buka perintah dalam mode administrator dan jalankan perintah berikut untuk menginstal tfx-cli.

npm install -g tfx-cli

4. Buat token akses pribadi dengan hak istimewa Akses penuh dan salin token tersebut. Token akses Pribadi ini akan digunakan saat menjalankan perintah login tfx.

5. Jalankan hal berikut ini dari perintah. Saat diminta, masukkan URL Layanan dan token akses Pribadi.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Jalankan perintah berikut untuk mengunggah tugas di server. Jalur paket yang diekstrak adalah D:\tasks (1)\AzurePowerShellv4.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 8: 8 September 2020

Kami telah merilis patch keamanan untuk Azure DevOps Server 2019.0.1 yang memperbaiki hal berikut. Lihat posting blog untuk informasi selengkapnya.

• DTS 1713492 - Perilaku tak terduga saat menambahkan grup AD ke izin keamanan.

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 7: 14 Juli 2020

Kami telah merilis patch keamanan untuk Azure DevOps Server 2019.0.1 yang memperbaiki hal berikut. Lihat posting blog untuk informasi selengkapnya.

• CVE-2020-1326: Kerentanan Scripting Lintas Situs
• Alur build menunjukkan koneksi yang salah untuk pengguna yang tidak sah saat memilih sumber Git Lainnya.
• Perbaikan kesalahan saat mengubah Pewarisan ke Aktif atau Nonaktif dalam definisi build XAML.

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 6: 10 Juni 2020

Kami telah merilis patch keamanan untuk Azure DevOps Server 2019.0.1 yang memperbaiki hal berikut. Lihat posting blog untuk informasi selengkapnya.

• CVE-2020-1327: Pastikan Azure DevOps Server membersihkan input pengguna
• Menambahkan dukungan untuk SHA2 di SSH di Azure DevOps

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 5: 10 Maret 2020

Kami telah merilis patch keamanan untuk Azure DevOps Server 2019.0.1 yang memperbaiki hal berikut. Lihat posting blog untuk informasi selengkapnya.

• CVE-2020-0700: Kerentanan Scripting Lintas Situs
• CVE-2020-0758: Elevasi Kerentanan Hak Istimewa
• CVE 2020-0815: Elevasi Kerentanan Hak Istimewa

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 3: 10 September 2019

Kami telah merilis patch keamanan untuk Azure DevOps Server 2019.0.1 yang memperbaiki bug berikut. Lihat posting blog untuk informasi selengkapnya.

• CVE-2019-1305: Kerentanan scripting lintas situs (XSS) dalam Repositori
• CVE-2019-1306: Kerentanan eksekusi kode jarak jauh di Wiki

---

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 2: 13 Agustus 2019

Kami telah merilis patch keamanan untuk Azure DevOps Server 2019.0.1 yang memperbaiki bug berikut. Lihat posting blog untuk informasi selengkapnya.

• Kami menambahkan informasi ke koneksi layanan untuk mengklarifikasi bahwa koneksi tersebut telah diotorisasi untuk semua alur secara default.

---

Tanggal Rilis Azure DevOps Server 2019.0.1 Patch 1: 9 Juli 2019

Kami telah merilis patch keamanan untuk Azure DevOps Server 2019.0.1 yang memperbaiki bug berikut. Lihat posting blog untuk informasi selengkapnya.

• CVE-2019-1072: Kerentanan eksekusi kode jarak jauh dalam pelacakan item kerja
• CVE-2019-1076: Kerentanan scripting lintas situs (XSS) dalam permintaan pull

---

Tanggal Rilis Azure DevOps Server 2019.0.1: 21 Mei 2019

Azure DevOps Server 2019.0.1 adalah serangkaian perbaikan bug. Ini mencakup semua perbaikan di patch Azure DevOps Server 2019 yang dirilis sebelumnya. Anda dapat langsung menginstal Azure DevOps Server 2019.0.1 atau meningkatkan dari Azure DevOps Server 2019 atau Team Foundation Server 2012 atau yang lebih baru.

Catatan

Alat Migrasi Data akan tersedia untuk Azure DevOps Server 2019.0.1 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

• "Terdapat kesalahan pada kriteria bidang untuk paket ini." saat mengonfigurasi Paket. Dilaporkan melalui Komunitas Pengembang.
• apiwitcontroller.executequery mengeluarkan pengecualian ketika kueri memiliki kolom yang sama beberapa kali.
• Dalam model objek klien menggunakan cakupan oauth vso.work_full, WorkItemServer.DownloadFile() mengalami kegagalan.
• Menyalin gambar yang disematkan dari bidang item kerja ke bidang item kerja lain di proyek lain dapat menghasilkan gambar yang rusak.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

• Tab Analitik Pengujian memiliki bintang (*) yang menunjukkan pratinjau, meskipun fitur ini tidak sedang dalam pratinjau.
• Pada tab Rilis, tindakan untuk mengelola keamanan kini ditampilkan kepada semua pengguna terlepas dari apakah mereka dapat mengubah izin atau tidak.
• Pada halaman arahan Rilis, tindakan mulai rilis draf membuat rilis baru, tetapi sekarang memulai rilis draf.

Azure Test Plans

• Filter 1 jam di TestRuns dan TestResults CompletedDate terlalu terperinci.
• Dalam tipe item kerja Kasus Pengujian, tipe "Kasus Pengujian" tidak boleh dilokalkan.
• Kasus pengujian tidak muncul di MTM atau browser.
• Kesalahan "Memvalidasi tahap: Anda tidak memiliki izin untuk memicu rilis pada alur rilis terkait" saat menjalankan pengujian otomatis dari Rencana Pengujian. Dilaporkan melalui Komunitas Pengembang.
• Dengan menggunakan API hapus kasus pengujian, kasus pengujian dapat dihapus dari proyek lain. Dilaporkan melalui Komunitas Pengembang.
• Mengeklik tautan item kerja di Runner Pengujian akan membuka URL item kerja di dalam Runner Pengujian bukannya browser default.
• Status kasus pengujian tidak akan diperbarui bagi pengguna yang keluar dari Runner Pengujian.
• Nama pengguna dan alamat email tidak ditampilkan di menu menurun pengguna dalam Runner Pengujian.

Azure Artifacts

• Pindah ke Atas dan Pindah ke Bawah tidak dilokalkan dalam Upstream.

Analitik

• Laporan analitik mungkin menampilkan data yang tidak lengkap karena model ditandai sebagai "siap" sebelum benar-benar lengkap.
• Widget kecepatan, burndown, dan burnup menampilkan berbagai pekerjaan terencana bagi pengguna di zona waktu yang berbeda.
• Penangguhan dapat ditempatkan pada penyerapan data Analytics saat melakukan pemeliharaan yang dapat menyebabkan laporan kedaluwarsa.

Umum

• Item navigasi kiri dipaksa masuk ke IE ketika ruang tidak cukup.

Administrasi

• Pengelogan tambahan ditambahkan ke peningkatan Koleksi untuk membantu men-debug masalah.
• Ketika TfsConfig offlineDetach gagal, pesan kesalahan tidak dapat ditindaklanjuti.
• Layanan TfsJobAgent mengalami crash.
• Ekstensi Pencarian tidak diinstal setelah konfigurasi selesai.
• Konsol Administrasi menjadi tidak responsif ketika konfigurasi DB rusak.
• Service Hook mungkin tidak memproses pemberitahuan dengan benar.
• Pengindeksan Pencarian Kode tidak dimulai setelah mengonfigurasi Pencarian.
• Ada string yang tidak dilokalkan di hasil halaman pencarian.

Rilis ini mencakup pembaruan berikut:

Dukungan untuk Visual Studio 2019 (VS2019) dalam tugas Visual Studio Test

Kami telah menambahkan dukungan untuk Visual Studio 2019 ke tugas Visual Studio Test dalam alur. Untuk menjalankan pengujian menggunakan platform pengujian untuk Visual Studio 2019, pilih opsi Terbaru atau Visual Studio 2019 dari menu menurun versi platform Pengujian.

---

Tanggal Rilis Azure DevOps Server 2019 Patch 2: 14 Mei 2019

Kami telah merilis patch keamanan untuk Azure DevOps Server 2019 yang memperbaiki bug berikut. Lihat posting blog untuk informasi selengkapnya.

• CVE-2019-0872: Kerentanan scripting lintas situs (XSS) dalam Rencana Pengujian
• CVE-2019-0971: Kerentanan pengungkapan informasi di API Repositori
• CVE-2019-0979: Kerentanan scripting lintas situs (XSS) dalam hub Pengguna

---

Tanggal Rilis Azure DevOps Server 2019 Patch 1: 9 April 2019

Kami telah merilis patch keamanan untuk Azure DevOps Server 2019 yang memperbaiki bug berikut. Lihat posting blog untuk informasi selengkapnya.

• CVE-2019-0857: Kerentanan spoofing di Wiki
• CVE-2019-0866: Kerentanan eksekusi kode jarak jauh di Pipelines
• CVE-2019-0867: Kerentanan scripting lintas situs (XSS) dalam Pipelines
• CVE-2019-0868: Kerentanan scripting lintas situs (XSS) dalam Pipelines
• CVE-2019-0869: Kerentanan injeksi HTML dalam Pipelines
• CVE-2019-0870: Kerentanan scripting lintas situs (XSS) dalam Pipelines
• CVE-2019-0871: Kerentanan scripting lintas situs (XSS) dalam Pipelines
• CVE-2019-0874: Kerentanan scripting lintas situs (XSS) dalam Pipelines
• CVE-2019-0875: Elevasi kerentanan hak istimewa di Boards

---

Tanggal Rilis Azure DevOps Server 2019: 5 Maret 2019

Catatan

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

---

Tanggal Rilis RC2: 22 Januari 2019

Ringkasan Yang Baru di RC2 Azure DevOps Server 2019

Kami telah menambahkan fitur berikut ke RC2:

• Link GitHub Enterprise melakukan dan menarik permintaan ke item kerja Azure Boards
• Mengonfigurasi build menggunakan YAML
• Anotasi kartu mencakup bug dan tipe item kerja kustom
• Pemilih cabang yang ditingkatkan
• Perubahan pada Artifacts dan Lisensi Alur Penyebaran Manajemen Rilis

---

Tanggal Rilis RC1: 19 November 2018

Ringkasan Yang Baru di RC1 Azure DevOps Server 2019

Azure DevOps Server 2019 memperkenalkan pengalaman navigasi baru dan banyak fitur baru. Beberapa sorotannya meliputi:

• Pengalaman navigasi baru
• Ekstensi marketplace Analytics untuk pelaporan kini tersedia
• Dukungan untuk Azure SQL Database
• Pewarisan proses pada koleksi baru
• Hub Item Kerja Baru
• Hub Board, Backlog, dan Sprint baru
• Hub Kueri Baru
• Menstandarkan deskripsi permintaan pull menggunakan templat
• Mengubah cabang target permintaan pull
• Mengelola alur build menggunakan halaman Build baru
• Mengelola alur rilis menggunakan halaman Rilis baru
• Memvisualisasikan kemajuan rilis
• Memperbarui agen Anda secara lokal
• Secara progresif mengekspos penyebaran dan fase menggunakan gerbang rilis
• Sumber upstream
• Membuat daftar isi untuk halaman wiki

Anda juga dapat langsung masuk ke bagian individual untuk melihat fitur baru:

• Umum
• Boards
• Repos
• Pipelines
• Test Plans
• Artefak
• Wiki
• Pelaporan

---

Umum

Mengumumkan Azure DevOps Server

Pada tanggal 10 September, kami mengumumkan Azure DevOps sebagai evolusi dari Visual Studio Team Services dan Team Foundation Server. Azure DevOps Server 2019 adalah rilis lokal pertama kami dengan merek baru ini. Anda dapat menemukan informasi selengkapnya di posting blog kami.

Pengalaman navigasi baru

Kami memperkenalkan navigasi baru untuk memodernisasi pengalaman pengguna. Navigasi baru ini telah diluncurkan ke layanan Azure DevOps dan sekarang tersedia di Azure DevOps Server 2019. Lihat blog kami untuk informasi selengkapnya.

Perubahan pada Artifacts dan Lisensi Alur Penyebaran Manajemen Rilis

Berdasarkan umpan balik pengguna, kami membuat dua perubahan utama pada lisensi kami di Azure DevOps Server 2019. Pertama, pelanggan tidak perlu lagi membeli ekstensi Artifact untuk menggunakan Artifacts. Penggunaan lisensi Artifacts sekarang akan disertakan dalam Lisensi Dasar. Semua pengguna dengan Lisensi Dasar yang ditetapkan untuk mereka sekarang dapat menggunakan Artifacts. Kedua, pelanggan tidak akan lagi diwajibkan untuk membeli Alur Penyebaran Manajemen Rilis. Sama seperti Alur Build, Alur Penyebaran Manajemen Rilis sekarang disertakan dengan Azure DevOps Server 2019.

Dukungan untuk Azure SQL Database

Untuk menyederhanakan pengalaman menjalankan Azure DevOps 2019 di Azure, kami telah mengaktifkan dukungan untuk Azure SQL Database (General Purpose S3 dan di atasnya). Ini akan memungkinkan Anda untuk memanfaatkan fitur pencadangan yang luas dan opsi penskalaan agar sesuai dengan kebutuhan Anda sambil mengurangi overhead administratif dari menjalankan layanan. Ingat bahwa VM Host Anda harus terletak di wilayah Azure yang sama dengan database agar menjaga latensi tetap rendah. Lihat dokumentasi untuk informasi selengkapnya.

Item kerja & menguji API SOAP model objek klien di versi mendatang

Azure DevOps Server 2019 terus mendukung API SOAP pelacakan item kerja dan model objek klien. Namun, ini akan ditandai sebagai tidak digunakan lagi di versi Azure DevOps Server mendatang. Anda dapat menemukan informasi selengkapnya di dokumentasi kami.

Pewarisan proses di koleksi baru

Pewarisan proses sekarang tersedia di koleksi baru. Pengguna harus mengambil keputusan yang dipikirkan matang-matang pada model proses saat membuat koleksi baru. Lihat dokumentasi kami tentang apa itu model pewarisan dan apa yang membedakannya dengan XML.

Kotak pencarian yang diperluas

Kami memahami pentingnya penelusuran dan menghadirkan kembali kotak pencarian yang diperluas di header produk. Selain itu, Anda sekarang dapat memanggil kotak pencarian hanya dengan mengeklik "/" di halaman layanan apa pun di Azure DevOps.

Berikut adalah kotak pencarian default:

Begitu mengetik "/", Anda akan melihat kotak pencarian yang diperluas:

Flyout kerja saya

Fitur baru yang tidak sabar untuk kami perkenalkan adalah flyout kerja saya. Kami mendengar umpan balik bahwa ketika Anda berada di salah satu bagian produk dan menginginkan beberapa informasi dari bagian lain, Anda tidak ingin kehilangan konteks. Dengan fitur baru ini, Anda dapat mengakses flyout ini dari mana saja di dalam produk, dan flyout akan memberi Anda sekilas informasi penting termasuk item kerja, permintaan pull, dan semua favorit. Dengan flyout baru ini, jika Anda berada di kepala Repositori dalam kode, tetapi kemudian ingin dengan cepat memeriksa item kerja mana yang harus dikerjakan berikutnya, cukup klik flyout dan lihat item kerja yang ditetapkan untuk Anda, lalu ambil item berikutnya.

Di bawah ini, Anda dapat melihat flyout kerja saya yang menunjukkan item kerja yang ditetapkan kepada saya:

Di sini, Anda dapat melihat pivot kedua yang menunjukkan PR yang ditetapkan kepada saya. Di flyout ini, Anda juga memiliki akses satu klik untuk melihat lebih banyak permintaan pull:

Di sini, Anda dapat melihat pivot terakhir, yang berisi semua favorit Anda. Ini mencakup tim, dasbor, board, backlog, kueri, dan repositori favorit Anda:

Boards

Penerapan dan permintaan pull tautan GitHub Enterprise ke item kerja Azure Boards

Tim yang menggunakan GitHub Enterprise untuk kode dan menginginkan kemampuan manajemen proyek yang kaya sekarang dapat mengintegrasikan repositori mereka dengan Azure Boards. Dengan menyambungkan GitHub dan Azure Boards, Anda bisa mendapatkan semua fitur seperti backlog, board, alat perencanaan sprint, beberapa tipe item kerja dan masih memiliki alur kerja yang terintegrasi dengan alur kerja pengembang di GitHub.

Penerapan dan permintaan pull penautan ke item kerja mudah dilakukan. Sebutkan item kerja menggunakan sintaks berikut:​

AB#{work item ID}

Sebutkan item kerja dalam pesan penerapan, judul permintaan pull, atau deskripsi permintaan pull, maka Azure Boards akan membuat tautan ke artefak tersebut. Misalnya, anggap pesan penerapan seperti ini:

Adds support for deleting connections. Fixes AB#20.

Ini akan membuat tautan dari item kerja #20 ke penerapan di GitHub, yang akan muncul di bagian Pengembangan dari item kerja. ​

Jika kata "fix", "fixes", atau "fixed" mendahului item kerja yang disebutkan (seperti yang ditunjukkan di atas), item kerja akan dipindahkan ke status selesai ketika penerapan digabungkan ke cabang default.

Tim yang menggunakan Azure Pipelines untuk menyusun kode di GitHub juga akan melihat item kerja yang ditautkan ke penerapan GitHub mereka dalam ringkasan build.

Hub Item Kerja Baru

Hub Item Kerja adalah hub baru kami yang akan berfungsi sebagai pusat dari item kerja Anda! Di sini, ada berbagai macam tampilan daftar dari item kerja yang terlingkup untuk Anda. Anda dapat melihat Ditetapkan kepada saya untuk melihat dengan cepat semua pekerjaan yang ditetapkan untuk Anda atau Baru-baru ini diperbarui yang menunjukkan semua item kerja dalam proyek yang baru-baru ini diperbarui. Semua opsi daftar Anda dapat dilihat di bawah ini:

Jika ingin mencakup daftar lebih jauh, Anda dapat memfilter pada jenis, ditetapkan ke, status, area, tag, dan kata kunci. Setelah mendapatkan tampilan daftar yang diinginkan, Anda kemudian dapat mengurutkan item kerja hanya dengan mengeklik header kolom. Jika satu kolom terlalu sempit untuk menampilkan konten kolom sepenuhnya, Anda dapat dengan mudah mengubah ukuran kolom di area header. Pengalaman ini dapat dilihat di bawah ini:

Hub Board, Backlog, dan Sprint baru

Hub Backlog dibagi menjadi tiga hub berbeda guna meningkatkan pengalaman pengguna. Meskipun kuat, hub Backlog lama adalah pusat dari begitu banyak fitur. Hal ini sering mempersulit pengguna untuk menemukan fitur atau kemampuan. Untuk mengatasi masalah ini, kami telah membagi hub Backlog menjadi:

• Hub Backlog sekarang menjadi pusat bagi backlog untuk suatu proyek saja. Backlog adalah daftar pekerjaan yang diprioritaskan untuk tim. Backlog menyediakan alat perencanaan seperti hierarki item kerja, prakiraan, dan pengalaman perencanaan sprint baru.
• Hub Board baru adalah pusat bagi semua Kanban Board untuk suatu proyek. Board digunakan untuk mengomunikasikan status dan alur. Kartu (item kerja) berpindah dari kiri ke kanan di seluruh board melalui kolom yang ditentukan oleh tim.
• Hub Sprint baru adalah pusat untuk fitur yang digunakan untuk merencanakan dan menjalankan peningkatan pekerjaan. Setiap sprint berisi backlog sprint, taskboard, dan tampilan untuk mengelola dan menetapkan kapasitas untuk tim.

Hub Kueri baru

Hub kueri baru menyederhanakan banyak fitur kueri yang ada dari hub lama dengan tampilan dan nuansa yang lebih modern serta menyediakan kemampuan baru agar mempermudah untuk masuk ke kueri yang penting bagi Anda. Beberapa sorotan dari pengalaman baru ini mencakup:

• Halaman direktori dengan informasi terakhir diubah oleh dan kemampuan untuk mencari kueri
• Breadcrumb dengan URL unik untuk folder guna menandai grup kueri penting
• Akses cepat ke kueri favorit Anda dari halaman hasil

Baca selengkapnya tentang pembaruan menarik ini di blog DevOps kami.

Memindahkan item kerja ke proyek lain dan mengubah tipe item kerja

Sekarang Anda dapat mengubah tipe item kerja atau memindahkan item kerja ke proyek lain dalam kumpulan proyek. Fitur-fitur ini mewajibkan gudang data dinonaktifkan. Dengan gudang data dinonaktifkan, Anda dapat menggunakan Analytics Service untuk mendukung kebutuhan pelaporan Anda. Untuk mempelajari selengkapnya tentang menonaktifkan gudang data, lihat Menonaktifkan gudang data dan kubus.

Fitur perencanaan sprint

Fitur perencanaan sprint baru membantu mempercepat dan meningkatkan pengalaman perencanaan sprint.

• Buat sprint Anda berikutnya atau berlangganan jadwal sprint yang ada langsung dari hub Sprint.
• Gunakan panel Perencanaan baru di backlog Anda untuk menyeret dan melepaskan item kerja ke dalam sprint mendatang. Panel Perencanaan mencakup tanggal sprint, jumlah item kerja, dan upaya yang direncanakan.
• Tambahkan persyaratan ke bagian atas Taskboard atau gunakan buat cepat untuk menambahkan ke bagian atas, bawah, atau baris pilihan pada backlog sprint Anda.
• Gunakan filter untuk Penerima Tugas, Tipe Item Kerja, Status, dan Tag untuk menyesuaikan tampilan dengan kebutuhan Anda.

Halaman Direktori baru

Semua hub baru, termasuk Backlog, Board, dan Sprint, sekarang memiliki halaman direktori baru yang diatur dengan bagian berikut:

• Lanjutkan pekerjaan Anda Bagian baru ini memberi tautan cepat langsung ke pekerjaan terakhir (Board | Backlog | Sprint) Anda.
• Favorit Semua board, sprint, dan backlog favorit Anda di semua tim.
• Milik Saya Semua board, backlog, dan sprint untuk tim Anda.
• Semua Daftar lengkap semua board, backlog, dan sprint Anda.

Menu Opsi Tampilan Baru

Hub baru, termasuk Backlog, Board, dan Sprint, memiliki menu Opsi Tampilan baru. Ini adalah pusat baru untuk semua tindakan yang menyesuaikan tata letak dan konten halaman. Gunakan Opsi Tampilan untuk mengaktifkan tampilan tambahan, seperti memperlihatkan hierarki di backlog atau mengubah opsi Kelompokkan Menurut di taskboard, untuk mengaktifkan panel samping untuk pemetaan dan perencanaan sprint, atau untuk menjelajahi bagan detail kerja.

Baca selengkapnya tentang pembaruan menarik ini, panel profil Tim baru, dan Favorit di blog DevOps kami.

Anotasi kartu mencakup bug dan tipe item kerja kustom

Anotasi kartu disukai karena tampilan dan interaksi daftar pemeriksaan intuitifnya. Sebelumnya, anotasi kartu terbatas pada jenis tingkat backlog default dan tidak mendukung Bug atau jenis kustom. Dengan rilis baru, kami telah menghapus pembatasan tipe item kerja dan menambahkan kemampuan untuk menampilkan Bug dan tipe item kerja kustom apa pun sebagai anotasi kartu.

Pengaturan board untuk anotasi kartu diperluas untuk menyertakan semua tipe item kerja yang tersedia untuk tingkat backlog tersebut.

Saat anotasi untuk item kerja diaktifkan, hitungan untuk tipe item kerja tersebut disertakan pada kartu sebagai daftar pemeriksaan terpisah.

Pembuatan cepat tipe item kerja yang diaktifkan juga tersedia melalui menu konteks kartu.

Memindahkan pekerjaan menggunakan Area dan Perulangan yang disarankan

Bekerja di area atau perulangan yang sama dan berulang kali menelusuri hierarki biasa dilakukan saat memindahkan item kerja. Kontrol jalur Area dan Perulangan sekarang menyertakan daftar nilai yang baru-baru ini digunakan sebagai Saran, memberi Anda akses cepat untuk mengatur dan melanjutkan.

Selain itu, tanggal Perulangan disertakan di sebelah kanan nama sehingga Anda dapat dengan cepat menilai kapan item kerja harus dikirimkan.

Kueri berfungsi di seluruh jadwal perulangan dengan +/- @CurrentIteration

Makro @CurrentIteration yang membantu tim Anda melacak pekerjaan berdasarkan jadwal perulangan Anda sekarang mendukung offset bilangan bulat. Simpan tab dengan mudah pada pekerjaan yang tidak ditutup dengan @CurrentIteration - 1, atau lihat pekerjaan yang direncanakan untuk perulangan berikutnya dengan @CurrentIteration + 1. Lihat posting @CurrentIteration di Blog Microsoft DevOps untuk informasi selengkapnya.

Mengklarifikasi jadwal perulangan kueri dengan parameter Tim @CurrentIteration

Jika pernah menggunakan makro @CurrentIteration dalam kueri sebelumnya, Anda mungkin telah mengetahui bahwa hasilnya dapat bervariasi jika konteks Tim berubah di seluruh Teams dengan jadwal perulangan yang berbeda. Sekarang, saat membuat atau mengubah kueri dengan makro @CurrentIteration, Anda juga akan diminta untuk memilih Tim dengan jadwal perulangan yang relevan dengan kueri. Dengan parameter Tim, Anda dapat menggunakan makro @CurrentIteration dalam kueri yang sama tetapi di seluruh tim. Salah satu contohnya mungkin kueri untuk item kerja dalam dua proyek tim yang berbeda menggunakan nama perulangan dan bahkan jadwal yang berbeda. Artinya tidak perlu lagi memperbarui kueri saat sprint berubah! Lihat posting @CurrentIteration di Blog Microsoft DevOps untuk informasi selengkapnya.

Kueri berfungsi di Jalur Area Tim dengan makro @TeamAreas baru

Dalam pengaturan untuk Tim, Anda dapat mengaitkan satu atau beberapa Jalur Area, yang membantu Anda memfokuskan Backlog, Board, Rencana, bahkan Dasbor hanya untuk pekerjaan tim tersebut. Namun, jika ingin menulis kueri untuk Tim, Anda harus mencantumkan Jalur Area tertentu untuk tim tersebut dalam klausa kueri. Sekarang, makro @TeamAreas baru tersedia agar Anda dapat dengan mudah mereferensikan Jalur Area yang dimiliki untuk Tim yang ditentukan.

Kueri untuk bidang teks kaya kosong

Temukan item kerja yang memiliki bidang teks kaya kosong, seperti Deskripsi, menggunakan operator kueri IsEmpty baru.

Menemukan dengan mudah item kerja yang ada dalam pengalaman menautkan dan menyebutkan

Jika ingin menautkan dua item kerja yang ada bersama-sama, kini Anda dapat dengan mudah menemukan item yang penting bagi Anda menggunakan kontrol pencarian item kerja baru kami. Pemilih kueri telah diganti dengan saran sebaris berdasarkan item kerja yang baru diakses, serta titik masuk untuk mencari item kerja tertentu menurut ID atau judul.

Membuka item kerja dari pencarian

Sebelumnya, item kerja tidak dapat dibuka dari halaman hasil pencarian jika panel pratinjau item kerja dinonaktifkan. Hal ini akan mempersulit proses mencari hasil pencarian Anda. Sekarang Anda dapat mengeklik judul item kerja untuk membuka item kerja di jendela modal.

Repos

Pemilih cabang yang ditingkatkan

Sebagian besar pengalaman di Azure Repos mewajibkan Anda untuk memilih repositori lalu cabang di repositori tersebut. Untuk meningkatkan pengalaman ini bagi organisasi dengan sejumlah besar cabang, kami meluncurkan pemilih cabang baru. Pemilih sekarang memungkinkan Anda untuk memilih cabang favorit atau dengan cepat mencari cabang.

Menerima pemberitahuan saat kebijakan permintaan pull dilewati

Untuk tim yang menggunakan permintaan pull (PR) dan kebijakan cabang, mungkin ada kesempatan ketika orang perlu menimpa dan melewati kebijakan tersebut - misalnya, saat menyebarkan perbaikan untuk masalah produksi di tengah malam. Masuk akal untuk memercayai pengembang untuk melakukan hal yang benar dan menggunakan kemampuan penimpaan dengan hemat. Pada saat yang sama, tim memerlukan cara untuk memverifikasi bahwa penimpaan kebijakan tersebut digunakan dalam situasi yang tepat. Untuk mendukung hal ini, kami telah menambahkan filter pemberitahuan baru untuk memungkinkan pengguna dan tim menerima pemberitahuan email setiap kali kebijakan dilewati. Dimulai dengan templat Permintaan pull dibuat atau diperbarui dan pilih Bypass Kebijakan dari daftar filter. Pilih Kebijakan telah dilewati sebagai nilai dan Anda akan diberi tahu setiap kali PR selesai dan kebijakan dilewati.

Mengizinkan bypass kebijakan cabang tanpa menyerahkan perlindungan push

Ada banyak skenario di mana Anda terkadang perlu melewati kebijakan cabang - mengembalikan perubahan yang menyebabkan kerusakan build, menerapkan hotfix di tengah malam, dll. Sebelumnya, kami menawarkan izin ("Dikecualikan dari penegakan kebijakan" ) untuk membantu tim mengelola pengguna mana yang diberi kemampuan untuk mengabaikan kebijakan cabang saat menyelesaikan permintaan pull. Namun, izin itu juga memberikan kemampuan untuk mendorong langsung ke cabang, melewati proses PR sepenuhnya.

Untuk meningkatkan pengalaman ini, kami telah membagi izin lama untuk menawarkan lebih banyak kontrol kepada tim yang memberikan izin bypass. Ada dua izin baru yang menggantikan izin lama:

1. Melewati kebijakan saat menyelesaikan permintaan pull. Pengguna dengan izin ini akan dapat menggunakan pengalaman "Penimpaan" untuk permintaan pull.
2. Melewati kebijakan saat mendorong. Pengguna dengan izin ini akan dapat mendorong langsung ke cabang dengan kebijakan yang diperlukan yang telah dikonfigurasi.

Dengan memberikan izin pertama dan menolak yang kedua, pengguna akan dapat menggunakan opsi bypass jika perlu, tetapi masih akan memiliki perlindungan agar tidak secara tidak sengaja mendorong ke cabang dengan kebijakan.

Catatan

Perubahan ini tidak memperkenalkan perubahan perilaku apa pun. Pengguna yang sebelumnya diberikan Izinkan untuk "Dikecualikan dari penegakan kebijakan" akan diberikan Izinkan untuk kedua izin baru, sehingga mereka dapat menimpa penyelesaian PR dan mendorong langsung ke cabang dengan kebijakan.

Lihat dokumentasi Atur izin cabang untuk informasi selengkapnya.

Menjelaskan permintaan pull dengan cepat menggunakan pesan penerapan

Menulis pesan penerapan deskriptif menambahkan nilai ke riwayat repositori Git. Untuk mendorong pesan penerapan kualitas, permintaan pull (PR) baru yang memiliki beberapa penerapan memerlukan kontributor untuk memasukkan judul secara manual.

Deskripsi permintaan pull akan terus kosong secara default, tetapi fitur baru akan memudahkan untuk memasukkan pesan penerapan dari penerapan PR ke dalam deskripsi PR. Untuk menambahkan pesan penerapan, cukup klik Tambahkan pesan penerapan untuk menambahkan pesan penerapan ke akhir teks deskripsi PR.

Membuat permintaan pull tanpa tim default sebagai peninjau

Ketika pertama kali meluncurkan pengalaman permintaan pull (PR), kami pikir masuk akal untuk menetapkan semua PR ke konteks tim yang telah Anda pilih saat membuat PR. Perilaku ini telah menjadi titik masalah, karena banyak orang tidak melihat koneksi antara konteks tim dan penugasan PR.

Sebagai bagian dari perubahan navigasi baru, kami mengambil kesempatan untuk mengubah asosiasi default ini dengan tim. Anda akan menyadari adanya dua perubahan:

1. Saat membuat PR, tidak ada peninjau yang ditambahkan secara default. Daftar peninjau memang memiliki fitur untuk mempermudah penambahan individu dan grup yang ditambahkan ke PR baru-baru ini. Kebijakan peninjau yang diperlukan juga dapat membantu tim yang ingin memastikan bahwa peninjau tertentu ditambahkan untuk meninjau kode mereka.
2. Hub Permintaan Pull memiliki bagian baru yang dapat disesuaikan. Secara default, bagian ini menunjukkan PR "Ditetapkan ke tim saya", menyediakan fungsionalitas yang setara sebagai bagian lama. Namun, jika Anda termasuk dalam beberapa tim, bagian ini akan menampilkan PR yang ditetapkan untuk salah satu tim Anda. Bagian ini juga dapat disesuaikan - cukup klik tindakan "Sesuaikan tampilan ini" di dekat header bagian.

Menstandarkan deskripsi permintaan pull menggunakan templat

Menulis deskripsi permintaan pull yang baik adalah cara yang bagus untuk membantu peninjau mengetahui apa yang diharapkan saat meninjau kode. Ini juga cara yang bagus untuk membantu melacak hal-hal yang perlu dilakukan untuk setiap perubahan, seperti pengujian, menambahkan pengujian unit, dan memperbarui dokumentasi. Banyak dari Anda telah meminta agar kami menambahkan templat permintaan pull untuk memudahkan tim menulis deskripsi bagus, dan kini kami telah menambahkan fitur tersebut.

Selain mendukung templat deskripsi PR default, tim dapat menambahkan beberapa templat, yang disajikan dalam menu di halaman buat PR. Cukup klik tombol Tambahkan templat untuk memilih dari templat apa pun di repositori untuk menambahkannya ke deskripsi PR.

Templat khusus cabang juga didukung jika Anda ingin menerapkan templat yang berbeda untuk PR ke cabang tertentu, atau folder cabang. Misalnya, jika ingin memiliki templat khusus untuk semua cabang yang dimulai dengan "hotfix/" Anda dapat menambahkan templat yang akan digunakan untuk semua PR ke cabang tersebut.

Lihat dokumentasi templat permintaan pull untuk mempelajari selengkapnya tentang cara membuat dan menggunakan templat.

Mengubah cabang target permintaan pull

Untuk sebagian besar tim, hampir semua permintaan pull menargetkan cabang yang sama, seperti main atau develop. Namun, dalam kasus saat Anda perlu menargetkan cabang yang berbeda, mudah untuk lupa mengubah cabang target dari default. Dengan fitur baru untuk mengubah cabang target permintaan pull aktif, ini sekarang menjadi tindakan sederhana. Cukup klik ikon pensil di dekat nama cabang target di header permintaan pull.

Selain memperbaiki kesalahan, fitur untuk mengubah cabang target juga memudahkan untuk "menargetkan ulang" permintaan pull ketika cabang target telah digabungkan atau dihapus. Pertimbangkan skenario saat ada PR yang menargetkan cabang fitur yang berisi beberapa fitur yang bergantung pada perubahan Anda. Anda ingin meninjau perubahan dependen dalam isolasi dari perubahan lain di cabang fitur, jadi awalnya Anda menargetkan features/new-feature. Lalu, peninjau hanya dapat melihat perubahan dan menuliskan komentar yang sesuai.

Sekarang, pertimbangkan apa yang akan terjadi jika cabang fitur juga memiliki PR aktif, dan digabungkan ke dalam main sebelum perubahan Anda? Sebelumnya, Anda harus meninggalkan perubahan dan membuat PR baru ke dalam main, atau menggabungkan PR ke dalam features/new-feature, lalu membuat PR lagi dari features/new-feature ke main. Dengan tindakan baru untuk memperbarui cabang target ini, Anda cukup mengubah cabang target PR dari features/new-feature menjadi main, mempertahankan semua konteks dan komentar. Mengubah cabang target bahkan membuat pembaruan baru ke PR yang memudahkan untuk melihat kembali perbedaan terakhir sebelum cabang target berubah.

Penulis ekstensi dapat mengkueri konteks tentang repositori saat ini

Salah satu tantangan bagi penulis ekstensi kontrol versi adalah mendapatkan konteks repositori yang ditampilkan kepada pengguna, seperti nama, ID, dan URL. Untuk membantu hal ini, kami menambahkan VersionControlRepositoryService sebagai layanan yang dapat diakses ekstensi. Dengan menggunakan ini, penulis ekstensi dapat mengkueri informasi tentang konteks repositori Git saat ini dalam antarmuka pengguna Web. Layanan ini memiliki satu metode, getCurrentGitRepository().

• Jika repositori Git dipilih, objek GitRepository dikembalikan dengan data dasar tentang repositori (nama, ID, dan URL)
• Jika repositori TFVC dipilih atau layanan diakses di luar halaman Azure Repos, null akan dikembalikan.

Berikut adalah ekstensi sampel yang menggunakan layanan ini.

Pipelines

Mengelola alur build menggunakan halaman Build baru

Kami melakukan beberapa penyempurnaan dan meluncurkan versi baru halaman Build. Versi baru ini menggabungkan direktori semua alur build dan daftar build saat ini sehingga Anda dapat dengan cepat menavigasi di seluruh build proyek untuk melihat statusnya. Ini juga mencakup pratinjau analitik pengujian untuk alur yang dipilih.

Mengelola email penyelesaian build dan penyebaran dengan lebih baik menggunakan pemformatan yang ditingkatkan

Email penyelesaian build dan penyebaran telah diperbarui agar lebih dapat difilter berdasarkan aturan email. Sekarang baris subjek mencakup informasi yang lebih relevan sekilas, isinya berisi detail lebih lanjut, dan gayanya telah diperbarui dengan merek terbaru.

Elemen format baru ini adalah:

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

Berikut beberapa contohnya:

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Mengikuti terminologi Azure Pipelines terpadu baru

Sepanjang build dan rilis, istilah yang berbeda telah digunakan secara historis untuk konsep serupa. Dalam kasus lain, arti dari istilah tidak jelas. Misalnya, memberi tahu perbedaan antara kumpulan agen dan antrean agen.

Terminologi telah dipadukan dalam Azure Pipelines untuk menjelaskan konsepnya. Sekarang Anda akan melihat istilah terpadu berikut ini:

Istilah sebelumnya	Istilah terpadu	Makna
Agen yang dihosting	Agen yang di-host Microsoft	Agen build/rilis yang berjalan pada infrastruktur dihosting cloud yang dikelola oleh Microsoft.
Agen privat	Agen yang di-host mandiri	Agen build/rilis yang berjalan pada komputer yang disediakan dan dikelola oleh Anda.
Kumpulan agen	Kumpulan agen	Sekumpulan komputer agen tingkat organisasi yang dapat menjalankan build atau rilis.
Antrean agen	Kumpulan agen	Sekumpulan komputer agen tingkat organisasi yang dapat menjalankan build atau rilis. Ini ditautkan ke kumpulan agen tingkat organisasi.
Definisi build	Alur build	Sekumpulan langkah build end-to-end untuk aplikasi.
Build	Build	Instans alur build yang sedang berjalan atau telah berjalan.
Fase	Tugas	Serangkaian tugas yang berjalan secara berurutan atau paralel di suatu agen. Alur build atau rilis dapat berisi satu pekerjaan atau grafik beberapa pekerjaan.
Definisi rilis	Alur rilis	Sekumpulan langkah rilis end-to-end untuk aplikasi yang akan disebarkan di berbagai tahap.
Rilis	Rilis	Instans alur rilis yang sedang berjalan atau telah berjalan.
Lingkungan	Tahap	Entitas logis dan independen yang menggambarkan lokasi tempat Anda ingin menyebarkan rilis yang dihasilkan dari alur rilis.
Pekerjaan/alur bersamaan	Pekerjaan paralel	Pekerjaan paralel memberi Anda kemampuan untuk menjalankan satu pekerjaan build atau rilis secara bersamaan di organisasi Anda. Dengan lebih banyak pekerjaan paralel yang tersedia, Anda dapat menjalankan lebih banyak pekerjaan build dan rilis secara bersamaan.
Titik akhir layanan	Koneksi layanan	Sekelompok pengaturan, seperti kredensial, digunakan untuk menyambungkan ke layanan eksternal untuk menjalankan tugas dalam build atau rilis.

Lihat dokumentasi Konsep untuk informasi selengkapnya.

Mengelola alur rilis menggunakan halaman Rilis baru

Pengalaman pengguna baru dan didesain ulang sepenuhnya tersedia untuk halaman arahan rilis. Lihat daftar alur rilis yang sering Anda rilis di sebelah kiri. Anda juga dapat mencari alur Anda dan memfavoritkannya.

Ubah ke tampilan folder untuk membuat folder untuk organisasi dan keamanan. Keamanan dapat diatur pada tingkat folder.

Memvisualisasikan kemajuan rilis

Tampilan kemajuan rilis baru memberi pembaruan langsung kemajuan penyebaran dan akses satu klik ke detail lebih lanjut. Tampilan baru memvisualisasikan alur rilis, sehingga lebih mudah untuk memahami apa yang sedang terjadi dan menampilkan detail serta tindakan yang sesuai pada berbagai tahap rilis.

Alur, detail rilis, dan lingkungan

Tampilan Alur menunjukkan artefak rilis dan lingkungan tempat artefak ini akan disebarkan. Area Rilis menyediakan detail rilis seperti pemicu rilis, versi artefak, dan tag.

Lingkungan dimodelkan dengan cara agar membantu memahami statusnya, beserta dengan kemajuan terperinci. Kapan saja, Anda dapat masuk ke log dengan mengeklik tautan status dalam lingkungan.

Pra-penyebaran dan pasca-penyebaran

Jika ketentuan pra-penyebaran atau pasca-penyebaran telah ditetapkan untuk suatu lingkungan, ini akan ditunjukkan di lingkungan dengan adanya persetujuan dan gerbang. Kemajuan persetujuan dan gerbang juga muncul di status lingkungan. Anda dapat mengambil tindakan atau melihat detail lebih lanjut dengan mengeklik ikon ketentuan lingkungan yang menggantung di sisi kanan atau kiri lingkungan.

Penerapan dan item kerja

Dengan setiap rilis baru, Anda dapat melihat daftar penerapan dan item kerja terkait untuk setiap lingkungan secara terpisah dengan mengeklik lingkungan. Jika daftarnya panjang, gunakan filter untuk menemukan penerapan atau item kerja yang Anda minati.

Kemajuan dan log penyebaran

Lingkungan menunjukkan pembaruan langsung untuk penyebaran yang sedang berlangsung, termasuk jumlah fase dan tugas yang selesai serta waktu yang berjalan. Mengeklik status lingkungan akan membuka tampilan yang berisi log, dengan fokus pada apa yang saat ini sedang aktif.

Anda dapat mengeklik log untuk memasukkan tampilan yang difokuskan.

Dampak peningkatan ke Azure DevOps Server 2019 pada tugas: Windows Machine File Copy dan PowerShell di Target Machine

Grup mesin di bawah Hub Pengujian tidak digunakan lagi di TFS 2017 RTM. Dengan Azure DevOps Server 2019, layanan grup Mesin tidak lagi tersedia. Ini akan berdampak pada pengguna tugas 'Windows Machine File Copy' versi 1.* dan tugas 'PowerShell on Target Machines' versi 1.*. Agar alur Anda terus berfungsi,

• Anda harus beralih ke tugas 'Windows Machine File Copy' versi 2.* dan menyediakan fqdn lengkap untuk komputer target, bukan hanya nama komputer.
• Dan beralihlah ke tugas 'Powershell on Target Machine' versi 2.* atau yang lebih baru dan berikan fqdn lengkap dari komputer atau nama komputer diikuti dengan port Windows Remote Management (http/https). Misalnya, targetMachine:5985 atau targetMachine:5986

Hasil dan ekstensibilitas pengujian

Hasil dari eksekusi pengujian juga muncul untuk setiap lingkungan. Mengeklik hasil pengujian akan membuka tampilan yang berisi detail pengujian termasuk hasil dari ekstensi lain yang berkontribusi pada proses ini.

Ekstensi yang ada berfungsi dalam tampilan baru ini,serta ada titik ekstensibilitas baru yang memungkinkan ekstensi berkembang agar menampilkan lebih banyak informasi untuk suatu lingkungan. Lihat dokumentasi kontribusi dan ekstensi untuk informasi selengkapnya.

Mengonfigurasi build menggunakan YAML

Alur build berbasis YAML tersedia di Azure DevOps Server Anda. Otomatiskan alur integrasi berkelanjutan Anda menggunakan file YAML yang dicentang ke repositori Anda. Referensi lengkap untuk skema YAML dapat ditemukan di sini.

Untuk mendukung alur build berbasis YAML dengan lebih mulus, kami mengubah perilaku default untuk semua sumber daya baru yang Anda buat (misalnya, koneksi layanan, grup variabel, kumpulan agen, dan file aman) agar dapat digunakan di semua alur proyek tersebut. Jika menginginkan kontrol yang lebih ketat pada sumber daya, Anda dapat menonaktifkan model otorisasi default (lihat gambar di bawah). Saat Anda melakukannya, seseorang dengan izin untuk menggunakan sumber daya harus secara eksplisit menyimpan alur di editor web setelah referensi sumber daya ditambahkan ke file YAML.

Build terkait rantai bersama-sama menggunakan pemicu penyelesaian build

Produk besar memiliki beberapa komponen yang bergantung satu sama lain. Komponen-komponen ini sering dibangun secara independen. Ketika komponen upstream (pustaka, misalnya) berubah, dependensi hilir harus dibangun kembali dan divalidasi ulang. Tim biasanya mengelola dependensi ini secara manual.

Kini Anda dapat memicu build setelah keberhasilan penyelesaian build lain. Artefak yang dihasilkan oleh build upstream dapat diunduh dan digunakan dalam build nanti, dan Anda juga dapat mengambil data dari variabel ini: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Lihat dokumentasi pemicu build untuk informasi selengkapnya.

Perlu diingat bahwa dalam beberapa kasus, satu build multi-fase dapat memenuhi kebutuhan Anda. Namun, pemicu penyelesaian build berguna jika persyaratan Anda mencakup pengaturan konfigurasi, opsi, atau tim yang berbeda untuk memiliki proses dependen.

Memperbarui agen Anda secara lokal

Tugas yang Anda instal dari Galeri terkadang memerlukan versi agen alur yang lebih baru. Jika Azure DevOps Server Anda dapat terhubung ke internet, versi yang lebih baru akan diunduh secara otomatis. Jika tidak, Anda harus meningkatkan setiap agen secara manual. Dimulai dengan rilis ini, Anda dapat mengonfigurasi Azure DevOps Server untuk mencari file paket agen di disk lokalnya daripada dari internet. Ini memberikan fleksibilitas dan kontrol atas versi agen apa yang Anda jadikan tersedia, tanpa harus mengekspos Azure DevOps Server ke internet.

URL lencana status build baru

Lencana build yang disematkan ke beranda repositori adalah cara umum untuk menunjukkan kesehatan repositori. Meskipun kami memiliki lencana build hingga saat ini, ada beberapa masalah:

• URL tidak intuitif
• Lencana tidak spesifik pada suatu cabang
• Tidak ada cara bagi pengguna untuk mengeklik lencana agar membawa pengguna ke build terbaru dari definisi tersebut

Saat ini kami meluncurkan API baru untuk lencana build yang mengatasi masalah ini. API baru memungkinkan pengguna untuk menerbitkan status per cabang dan dapat membawa pengguna ke build terbaru dari cabang yang dipilih. Anda dapat memperoleh Markdown untuk URL lencana status baru dengan memilih tindakan menu Lencana Status di halaman Build baru.

Untuk kompatibilitas mundur, kami akan terus menghargai URL lencana build yang lebih lama juga.

Menambahkan penghitung build kustom ke build Anda

Penghitung build menyediakan cara untuk memberi nomor dan label secara unik pada build. Sebelumnya, Anda dapat menggunakan variabel khusus $(rev:r) untuk melakukan hal ini. Sekarang Anda dapat menentukan variabel penghitung sendiri dalam definisi build Anda yang dinaikkan secara otomatis setiap kali menjalankan build. Lakukan ini di tab variabel definisi. Fitur baru ini memberikan lebih banyak fungsi sebagai berikut:

• Anda dapat menentukan penghitung kustom dan mengatur nilai awalnya. Misalnya, Anda dapat memulai penghitung di 100. $(rev:r) selalu dimulai dari 0.
• Anda dapat menggunakan logika kustom sendiri untuk mengatur ulang penghitung. $(rev:r) terkait dengan pembuatan nomor build, dan diatur ulang secara otomatis setiap kali ada awalan baru dalam nomor build.
• Anda dapat menentukan beberapa penghitung per definisi.
• Anda dapat mengkueri nilai penghitung di luar build. Misalnya, Anda dapat menghitung jumlah build yang telah berjalan sejak pengaturan ulang terakhir menggunakan penghitung.

Lihat dokumentasi tentang Variabel yang ditentukan pengguna untuk informasi selengkapnya tentang penghitung build.

Kepatuhan Azure Policy dan validasi keamanan di Pipelines

Kami ingin memastikan stabilitas dan keamanan perangkat lunak di awal proses pengembangan sembari menyatukan pengembangan, keamanan, dan operasi. Untuk melakukannya, kami telah menambahkan dukungan untuk Azure Policy.

Azure Policy membantu Anda mengelola dan mencegah masalah IT dengan definisi kebijakan yang menerapkan aturan dan efek untuk sumber daya Anda. Saat Anda menggunakan Azure Policy, sumber daya tetap mematuhi standar perusahaan dan perjanjian tingkat layanan Anda.

Guna mematuhi pedoman kepatuhan dan keamanan sebagai bagian dari proses rilis, kami telah meningkatkan pengalaman penyebaran grup sumber daya Azure kami. Sekarang, kami gagal dalam tugas penyebaran Grup Sumber Daya Azure dengan kesalahan terkait kebijakan yang relevan jika terjadi pelanggaran saat menyebarkan templat ARM.

Selain itu, kami telah menambahkan templat definisi Rilis Azure Policy. Ini akan memungkinkan pengguna untuk membuat kebijakan Azure dan menetapkan kebijakan ini ke sumber daya, langganan, atau grup manajemen dari definisi rilis itu sendiri.

Build di platform Linux/ARM dan Windows 32-bit

Sumber terbuka, agen lintas platform Azure Pipelines selalu didukung di Windows 64-bit (x64), macOS, dan Linux. Dengan rilis ini, kami memperkenalkan dua platform baru yang didukung: Linux/ARM dan Windows/32-bit. Platform baru ini memberi Anda kemampuan untuk membangun platform yang kurang umum, tetapi sama pentingnya, seperti Raspberry Pi, komputer Linux/ARM.

Pengalaman yang ditingkatkan untuk Pengujian dalam Pipelines

Tab Pengujian sekarang memiliki pengalaman modern yang memberi Anda informasi pengujian dalam konteks yang kaya untuk Pipelines. Pengalaman baru ini memberikan tampilan pengujian yang sedang berlangsung, pengalaman debug halaman penuh, riwayat pengujian dalam konteks, pelaporan eksekusi pengujian yang dibatalkan, dan ringkasan tingkat proses.

Menampilkan eksekusi pengujian yang sedang berlangsung

Pengujian, seperti pengujian integrasi dan fungsional, dapat berjalan untuk waktu yang lama sehingga penting untuk melihat eksekusi pengujian pada waktu tertentu. Dengan Tampilan Pengujian yang Sedang Berlangsung, Anda tidak perlu lagi menunggu eksekusi pengujian selesai untuk mengetahui hasilnya. Hasil tersedia mendekati real-time saat dijalankan, membantu Anda mengambil tindakan lebih cepat. Anda dapat men-debug kegagalan atau pembatalan, mengajukan bug, atau membatalkan alur. Fitur ini saat ini tersedia untuk alur build dan rilis menggunakan Vs Test Task di fase Multi Agen, menggunakan Terbitkan Tugas Hasil Pengujian, atau menerbitkan hasil pengujian menggunakan API. Di masa mendatang, kami berencana untuk memperluas pengalaman ini untuk eksekusi pengujian menggunakan Agen Tunggal.

Tampilan di bawah ini menunjukkan ringkasan Pengujian yang Sedang Berlangsung dalam tampilan kemajuan rilis baru, melaporkan jumlah pengujian total dan jumlah kegagalan pengujian pada poin waktu tertentu.

Dengan mengeklik ringkasan Pengujian yang Sedang Berlangsung di atas, Anda dapat menampilkan ringkasan pengujian terperinci serta informasi pengujian yang gagal atau dibatalkan dalam Rencana Pengujian. Ringkasan pengujian di-refresh secara berkala dengan kemampuan untuk memperbarui tampilan detail sesuai permintaan, berdasarkan ketersediaan hasil baru.

Menampilkan detail penelusuran kesalahan uji coba di halaman penuh

Pesan kesalahan dan jejak tumpukan bersifat panjang dan membutuhkan real estat yang cukup untuk menampilkan detail selama penelusuran kesalahan. Demi mendapatkan pengalaman debug yang imersif, kini Anda dapat memperluas tampilan pengujian atau uji coba ke tampilan halaman penuh, sambil tetap dapat melakukan operasi dalam konteks yang diperlukan seperti pembuatan bug atau asosiasi persyaratan untuk hasil pengujian saat ini.

Menampilkan riwayat pengujian dalam konteks

Secara historis, tim harus pergi ke hub Eksekusi untuk melihat riwayat hasil pengujian. Dengan pengalaman baru, kami menghadirkan riwayat pengujian yang tepat dalam konteks dalam tab Rencana Pengujian untuk build dan rilis. Informasi riwayat pengujian disediakan secara progresif yang dimulai dengan definisi atau lingkungan build saat ini untuk pengujian yang dipilih, diikuti oleh cabang dan lingkungan lain untuk build dan rilis masing-masing.

Menampilkan pengujian yang dibatalkan

Eksekusi pengujian dapat dibatalkan karena beberapa alasan seperti kode pengujian yang buruk, sumber di pengujian, dan masalah lingkungan. Terlepas dari alasan pembatalan, penting bagi Anda untuk mendiagnosis perilaku dan mengidentifikasi akar penyebabnya. Anda sekarang dapat menampilkan pengujian yang dibatalkan dan uji coba, bersamaan dengan eksekusi yang telah selesai dalam Rencana Pengujian. Fitur tersebut saat ini tersedia untuk jalur build dan rilis menggunakan VS Test Task dalam fase Multi Agen atau menerbitkan hasil pengujian menggunakan API. Di masa mendatang, kami berencana untuk memperluas pengalaman ini untuk eksekusi pengujian menggunakan Agen Tunggal.

Uji keterlacakan dan dukungan lingkungan rilis di Riwayat Pengujian

Kami menambahkan dukungan untuk menampilkan riwayat pengujian otomatis yang dikelompokkan berdasarkan berbagai lingkungan rilis tempat pengujian dijalankan. Jika Anda memodelkan lingkungan rilis sebagai alur rilis atau lingkungan pengujian, lalu menjalankan pengujian di seluruh lingkungan tersebut, Anda dapat mengetahui apakah pengujian lulus di lingkungan dev, tetapi gagal di lingkungan Integrasi. Anda dapat mengetahui apakah ini lewat di lokal bahasa Inggris, tetapi gagal di lingkungan yang memiliki lokal Turki. Untuk setiap lingkungan, Anda akan menemukan status hasil pengujian terbaru, dan jika pengujian telah gagal pada lingkungan tersebut, Anda juga akan menemukan rilis karena pengujian tersebut telah gagal.

Meninjau hasil pengujian yang diringkas

Selama eksekusi pengujian, pengujian mungkin menghasilkan beberapa instans pengujian yang berkontribusi pada keseluruhan hasil. Beberapa contoh meliputi: pengujian yang dijalankan kembali karena kegagalan, pengujian yang terdiri dari kombinasi berurutan dari pengujian lain (mis. pengujian terurut), atau pengujian yang memiliki instans berbeda berdasarkan parameter input yang diberikan (pengujian berbasis data). Karena pengujian-pengujian ini terkait, mereka perlu dilaporkan bersama dengan hasil keseluruhan yang diturunkan berdasarkan hasil pengujian individu. Dengan pembaruan ini, kami memperkenalkan versi yang disempurnakan dari hasil pengujian yang disajikan sebagai hierarki di tab Pengujian pada rilis. Mari kita lihat contohnya.

Sebelumnya, kami memperkenalkan kemampuan untuk menjalankan ulang pengujian yang gagal dalam tugas Pengujian VS. Namun, kami hanya melaporkan upaya terakhir dari pengujian, yang agak membatasi kegunaan fitur ini. Kami sekarang telah memperluas fitur ini untuk melaporkan setiap instans eksekusi pengujian sebagai upaya. Selain itu, API Manajemen Pengujian sekarang mendukung kemampuan untuk menerbitkan dan mengkueri hasil pengujian hierarki. Lihat dokumentasi API Hasil pengujian untuk informasi selengkapnya.

Catatan

Metrik di bagian ringkasan pengujian (mis., Total pengujian, Lulus, dll.), dihitung menggunakan tingkat akar hierarki daripada setiap perulangan individual pengujian.

Menampilkan analitik pengujian di Pipelines

Melacak kualitas pengujian dari waktu ke waktu dan meningkatkan jaminan pengujian adalah kunci untuk mempertahankan alur yang sehat. Fitur analitik pengujian memberikan visibilitas mendekati real-time ke dalam data pengujian Anda untuk build dan alur rilis. Ini membantu meningkatkan efisiensi alur Anda dengan mengidentifikasi masalah kualitas yang berulang dan berdampak tinggi.

Anda dapat mengelompokkan hasil pengujian berdasarkan berbagai elemen, mengidentifikasi pengujian utama untuk cabang atau file pengujian Anda, atau menelusuri paling detail pengujian tertentu untuk menampilkan tren dan memahami masalah kualitas seperti kelemahan.

Lihat analitik pengujian untuk build dan rilis, pratinjau di bawah ini:

Untuk informasi selengkapnya, lihat dokumentasi kami.

Menyederhanakan definisi dengan beberapa tugas tanpa agen

Tugas dalam fase tanpa agen diatur oleh dan dijalankan di server. Fase tanpa agen tidak memerlukan agen atau komputer target apa pun. Tidak seperti fase agen, hanya satu tugas yang dapat ditambahkan ke setiap fase tanpa agen dalam definisi. Ini berarti beberapa fase harus ditambahkan ketika ada lebih dari satu tugas tanpa agen dalam proses, membuat definisi menjadi besar. Kami telah melonggarkan pembatasan ini, yang memungkinkan Anda mempertahankan beberapa tugas dalam fase tanpa agen. Tugas dalam fase yang sama akan dijalankan secara berurutan, seperti yang dilakukan untuk fase agen. Lihat dokumentasi fase server untuk informasi selengkapnya.

Secara progresif mengekspos dan membuat fase penyebaran menggunakan gerbang rilis

Dengan menggunakan gerbang rilis, Anda dapat menentukan kriteria kesehatan aplikasi yang harus dipenuhi sebelum rilis dipromosikan ke lingkungan berikutnya. Semua gerbang yang ditentukan dievaluasi secara berkala sebelum atau setelah penyebaran, hingga berhasil diselesaikan. Empat jenis gerbang tersedia di luar kotak dan Anda dapat menambahkan lebih banyak gerbang dari Marketplace. Anda akan dapat mengaudit bahwa semua kriteria yang diperlukan untuk penyebaran telah terpenuhi. Lihat dokumentasi untuk gerbang rilis untuk informasi selengkapnya.

Menahan penyebaran hingga gerbang berhasil diselesaikan secara konsisten

Gerbang rilis memungkinkan evaluasi otomatis kriteria kesehatan sebelum rilis dipromosikan ke lingkungan berikutnya. Secara default, rilis berlangsung setelah satu sampel yang berhasil untuk semua gerbang telah diterima. Bahkan jika suatu gerbang tidak menentu dan sampel yang berhasil diterima adalah kebisingan, rilis tetap berjalan. Untuk menghindari jenis masalah ini, Anda sekarang dapat mengonfigurasi rilis untuk memverifikasi konsistensi kesehatan selama durasi minimum sebelum berprogres. Pada durasi, rilis akan memastikan evaluasi berturut-turut gerbang berhasil diselesaikan sebelum mengizinkan promosi. Total waktu untuk evaluasi tergantung pada "waktu antara evaluasi ulang" dan biasanya akan lebih dari durasi minimum yang dikonfigurasi. Lihat dokumentasi Kontrol penyebaran rilis menggunakan gerbang untuk informasi selengkapnya.

Secara otomatis menyebarkan ke target baru dalam grup penyebaran

Sebelumnya, ketika target baru ditambahkan ke grup penyebaran, penyebaran manual diperlukan untuk memastikan semua target memiliki rilis yang sama. Anda sekarang dapat mengonfigurasi lingkungan untuk secara otomatis menyebarkan rilis terakhir yang berhasil diselesaikan ke target baru. Lihat dokumentasi Grup Penyebaran untuk informasi selengkapnya.

Terus menyebarkan build yang ditandai oleh pemrosesan pasca-build

Pemicu penyebaran berkelanjutan membuat rilis pada penyelesaian build. Namun, terkadang build telah diproses dan build hanya boleh dirilis setelah pemrosesan tersebut selesai. Sekarang Anda dapat memanfaatkan tag build, yang akan ditetapkan selama pasca-pemrosesan, dalam filter pemicu rilis.

Mengatur variabel pada waktu rilis

Dalam definisi rilis, sekarang Anda dapat memilih variabel yang ingin diatur saat membuat rilis.

Nilai yang disediakan untuk variabel saat rilis dibuat hanya digunakan untuk rilis tersebut. Fitur ini akan membantu Anda menghindari beberapa langkah untuk Buat-di-Draf, memperbarui variabel dalam draf, dan memicu rilis dengan variabel.

Meneruskan variabel lingkungan ke tugas

Penulis tugas CI/CD dapat mengatur properti baru, showEnvironmentVariables, di task.json untuk meneruskan variabel lingkungan ke tugas. Ketika Anda melakukannya, kontrol ekstra dirender di tugas dalam editor build. Ini tersedia untuk tugas Powershell, Cmd, dan Bash.

Ini memungkinkan dua skenario:

• Suatu tugas memerlukan variabel lingkungan dengan kasus yang dipertahankan dalam nama variabel. Misalnya, dalam contoh di atas, variabel lingkungan yang diteruskan ke tugas adalah “foo” dan bukan “FOO”.
• Ini memungkinkan nilai rahasia untuk diteruskan dengan cara yang aman ke skrip. Cara ini lebih banyak dipilih untuk meneruskan rahasia sebagai argumen ke skrip karena sistem operasi di agen dapat mencatat pemanggilan proses termasuk argumennya.

Mengkloning grup variabel

Kami telah menambahkan dukungan untuk mengkloning grup variabel. Setiap kali ingin mereplikasi grup variabel dan hanya memperbarui beberapa variabel, Anda tidak perlu melalui proses yang membosankan untuk menambahkan variabel satu per satu. Sekarang Anda dapat dengan cepat membuat salinan grup variabel, memperbarui nilainya dengan tepat, dan menyimpannya sebagai grup variabel baru.

Catatan

Nilai variabel rahasia tidak disalin saat Anda mengkloning grup variabel. Anda perlu memperbarui variabel terenkripsi lalu menyimpan grup variabel yang dikloning.

Mengabaikan gerbang rilis untuk penyebaran

Gerbang rilis memungkinkan evaluasi otomatis kriteria kesehatan sebelum rilis dipromosikan ke lingkungan berikutnya. Secara default, alur rilis hanya berprogres ketika semua gerbang sehat pada saat yang sama. Dalam situasi tertentu, seperti ketika mempercepat rilis atau setelah memeriksa kesehatan secara manual, pemberi izin mungkin ingin mengabaikan gerbang dan memungkinkan rilis untuk berprogres bahkan jika gerbang itu belum dievaluasi sebagai gerbang yang sehat. Lihat dokumentasi gerbang rilis untuk informasi selengkapnya.

Melakukan pengujian tambahan menggunakan pemicu rilis permintaan pull

Anda telah dapat memicu build berdasarkan permintaan pull (PR) dan mendapatkan umpan balik cepat tersebut sebelum penggabungan untuk sementara waktu. Sekarang Anda juga dapat mengonfigurasi pemicu PR untuk rilis. Status rilis akan diposting kembali ke repositori kode dan dapat langsung dilihat di halaman PR. Ini berguna jika Anda ingin melakukan pengujian fungsional atau manual tambahan sebagai bagian dari alur kerja PR Anda.

Membuat koneksi layanan Azure dengan perwakilan layanan yang mengautentikasi dengan sertifikat

Sekarang Anda dapat menentukan koneksi layanan Azure dengan perwakilan layanan dan sertifikat untuk autentikasi. Dengan koneksi layanan Azure sekarang mendukung perwakilan layanan yang mengautentikasi dengan sertifikat, Anda sekarang dapat menyebarkan ke Azure Stack YANG dikonfigurasi dengan Active Directory Federation Services. Untuk membuat perwakilan layanan dengan autentikasi sertifikat, lihat artikel tentang cara membuat perwakilan layanan yang mengautentikasi dengan sertifikat.

Jalankan dari Paket yang didukung dalam penyebaran Azure App Service

Versi (4.*) tugas Penyebaran Azure App Service sekarang mendukung RunFromPackage (sebelumnya disebut RunFromZip).

App Service mendukung sejumlah teknik berbeda untuk menyebarkan file Anda seperti msdeploy (alias WebDeploy), git, ARM, dan banyak lagi. Namun, semua teknik ini memiliki batasan. File Anda disebarkan di folder wwwroot (khususnya d:\home\site\wwwroot) dan runtime bahasa umum kemudian menjalankan file dari sana.

Dengan Jalankan dari Paket, tidak ada lagi langkah penyebaran yang menyalin file individual ke wwwroot. Sebagai gantinya, arahkan ke file zip, dan zip akan dipasang di wwwroot sebagai sistem file baca-saja. Ini memiliki beberapa manfaat:

• Mengurangi risiko masalah penguncian salinan file.
• Dapat digunakan ke aplikasi produksi (dengan restart).
• Anda dapat yakin dengan file yang sedang berjalan di aplikasi Anda.
• Meningkatkan performa penyebaran Azure App Service.
• Dapat mengurangi waktu mulai dingin, terutama untuk fungsi JavaScript dengan pohon paket npm besar.

Menyebarkan kontainer Linux dengan tugas Penyebaran Server Aplikasi

Versi 4.* dari tugas Penyebaran Azure App Service sekarang mendukung penyebaran kontainer kustom Anda sendiri ke Azure Functions di Linux.

Model hosting Linux untuk Azure Functions didasarkan pada kontainer Docker yang membawa fleksibilitas lebih besar dalam hal pengemasan dan memanfaatkan dependensi spesifik aplikasi. Functions di Linux dapat dihosting dalam 2 mode berbeda:

1. Gambar kontainer bawaan: Anda membawa kode Aplikasi Fungsi dan Azure menyediakan serta mengelola kontainer (mode gambar bawaan) sehingga pengetahuan terkait Docker tertentu tidak diperlukan. Ini didukung dalam versi tugas Penyebaran App Service yang ada.
2. Gambar kontainer kustom: Kami telah meningkatkan tugas penyebaran App Service untuk mendukung penyebaran gambar kontainer kustom ke Azure Functions di Linux. Saat fungsi Anda memerlukan versi bahasa tertentu atau memerlukan dependensi atau konfigurasi tertentu yang tidak disediakan dalam gambar bawaan, Anda dapat menyusun dan menyebarkan gambar kustom ke Azure Function di Linux dengan menggunakan Azure Pipelines.

Tugas Xcode mendukung Xcode 10 yang baru dirilis

Bertepatan dengan rilis Xcode 10 Apple, sekarang Anda dapat mengatur proyek untuk menyusun atau diuji secara khusus dengan Xcode 10. Alur Anda juga dapat menjalankan pekerjaan secara paralel dengan matriks dari versi Xcode. Anda dapat menggunakan kumpulan agen macOS yang dihosting Microsoft untuk menjalankan build ini. Lihat panduan untuk menggunakan Xcode di Azure Pipelines.

Menyederhanakan penerapan ke Kubernetes menggunakan Helm

Helm adalah alat yang menyederhanakan penginstalan dan pengelolaan aplikasi Kubernetes. Alat ini juga meraih banyak popularitas dan dukungan komunitas tahun lalu. Tugas Helm dalam Rilis sekarang tersedia untuk pengemasan dan penyebaran bagan Helm ke Azure Container Service (AKS) atau kluster Kubernetes lainnya.

Dengan penambahan tugas Helm ini, sekarang Anda dapat menyiapkan alur CI/CD berbasis Helm untuk mengirimkan kontainer ke dalam kluster Kubernetes. Lihat dokumentasi Menyebarkan menggunakan Kubernetes ke Azure Container Service untuk informasi selengkapnya.

Mengontrol versi Helm yang digunakan dalam Rilis

Tugas Penginstal Alat Helm memperoleh versi Helm tertentu dari internet atau cache alat dan menambahkannya ke PATH agen (dihosting atau privat). Gunakan tugas ini untuk mengubah versi Helm yang digunakan dalam tugas berikutnya seperti tugas .NET Core cli. Menambahkan tugas ini sebelum tugas Penyebaran Helm dalam definisi build atau rilis memastikan Anda mengemas dan menyebarkan aplikasi dengan versi Helm yang tepat. Tugas ini juga membantu dalam menginstal alat kubectl secara opsional, yang merupakan prasyarat agar Helm dapat berfungsi.

Terus menyebarkan ke Azure Database for MySQL

Sekarang Anda dapat terus menyebarkan ke Azure Database for MySQL - Database MySQL Azure sebagai layanan. Kelola file skrip MySQL Anda dalam kontrol versi dan terus sebarkan sebagai bagian dari alur rilis menggunakan tugas asli daripada skrip PowerShell.

Menggunakan tugas berbasis PowerShell jarak jauh Windows yang ditingkatkan

Tugas baru dan yang ditingkatkan Windows berbasis PowerShell jarak jauh tersedia. Peningkatan ini mencakup beberapa perbaikan performa dan mendukung log langsung dan perintah output konsol, seperti Write-Host dan Write-Output.

Tugas PowerShell di Target (versi: 3.*): Anda dapat menambahkan skrip sebaris, mengubahi opsi PSSession, mengontrol "ErrorActionPreference", dan gagal pada kesalahan standar.

Tugas Salin File Azure (versi: 2.*): Dikirim dengan AzCopy terbaru (v7.1.0) yang mengatasi masalah GitHub.

Cabang filter untuk GitHub Enterprise atau artefak Git eksternal

Saat merilis dari repositori Git GitHub Enterprise atau eksternal, sekarang Anda dapat mengonfigurasi cabang tertentu yang akan dirilis. Misalnya, Anda mungkin ingin menyebarkan build yang berasal dari cabang tertentu saja ke produksi.

Aplikasi build yang ditulis dalam Go

Gunakan tugas Alat Penginstal Go Tool untuk menginstal satu atau beberapa versi Go Tool dengan cepat. Tugas ini memperoleh versi spesifik Go Tool yang diperlukan oleh proyek Anda dan menambahkannya ke PATH agen build. Jika versi Go Tool yang ditargetkan sudah diinstal pada agen, tugas ini akan melewati proses pengunduhan dan menginstalnya lagi.

Tugas Go membantu Anda mengunduh dependensi, menyusun, atau menguji aplikasi Anda. Anda juga dapat menggunakan tugas ini untuk menjalankan perintah Go kustom pilihan Anda.

Menjalankan skrip Python sebaris atau berbasis file di alur Anda

Tugas Skrip Python baru menyederhanakan menjalankan skrip Python di alur Anda. Tugas ini akan menjalankan skrip dari file Python (.py) di repositori, atau Anda dapat memasukkan skrip secara manual di pengaturan tugas, untuk disimpan sebagai bagian dari alur Anda. Tugas ini akan menggunakan versi Python di jalur, atau Anda dapat menentukan jalur absolut ke interpreter Python untuk digunakan.

Memanfaatkan build Xcode yang ditingkatkan dan output pengujian dari xcpretty

xcpretty meningkatkan keterbacaan output xcodebuild dan menghasilkan hasil pengujian dalam format JUnit. Tugas build Xcode sekarang secara otomatis menggunakan xcpretty ketika tersedia di komputer agen, seperti pada agen macOS yang dihosting. Meskipun output xcpretty dapat berbeda dan kurang verbose daripada output xcodebuild, kami membuat log xcodebuild lengkap tersedia di setiap build.

Test Plans

Klien Test Runner (Azure Test Plans) menjalankan pengujian manual untuk aplikasi desktop

Anda sekarang dapat menggunakan klien Test Runner (Azure Test Plans) untuk menjalankan pengujian manual untuk aplikasi desktop. Hal ini akan membantu Anda berpindah dari Microsoft Test Manager ke Azure Test Plans. Silakan lihat panduan kami di sini. Dengan menggunakan klien Test Runner, Anda dapat menjalankan pengujian manual dan merekam hasil pengujian untuk setiap langkah pengujian. Anda juga memiliki kemampuan pengumpulan data seperti cuplikan layar, log tindakan gambar, dan perekaman video audio. Jika Anda menemukan masalah saat pengujian, gunakan Test Runner untuk membuat bug dengan langkah-langkah pengujian, cuplikan layar, dan komentar yang secara otomatis disertakan dalam bug.

Test Runner (Azure Test Plans) memerlukan pengunduhan dan penginstalan runner satu kali. Pilih Jalankan untuk aplikasi desktop seperti yang ditunjukkan di bawah ini.

Artefak

Sumber upstream

Azure DevOps Server 2019 menghadirkan pembaruan substansial untuk sumber upstream yang tersedia di umpan Azure Artifacts Anda:

• Anda dapat menambahkan sumber upstream nuget.org ke umpan yang sudah ada yang dibuat di rilis TFS sebelumnya. Cari banner di atas paket umpan Anda untuk informasi selengkapnya, termasuk perubahan perilaku yang harus diketahui sebelum meningkatkan.
• Anda dapat menambahkan umpan Azure DevOps Server lain sebagai sumber upstream ke umpan, yang berarti Anda dapat menggunakan paket NuGet dan npm dari umpan tersebut melalui umpan.

Kami juga telah memperkenalkan peran baru di Azure Artifacts: "Collaborator". Kolaborator dapat menyimpan paket dari sumber upstream, tetapi tidak dapat menerbitkan paket langsung ke umpan (misalnya, dengan menggunakan penerbitan nuget). Hal ini memungkinkan Anda untuk membatasi penerbitan paket ke pengguna atau sistem build tepercaya sembari memungkinkan teknisi Anda menggunakan paket baru dari sumber upstream.

Mengikuti paket

Kami telah mempermudah penyiapan pemberitahuan dengan tombol Ikuti baru langsung di setiap paket. Tombol Ikuti juga kompatibel dengan tampilan rilis. Jika mengikuti paket saat melihatnya melalui tampilan, Anda hanya akan mendapatkan pembaruan untuk versi baru yang dipromosikan ke tampilan tersebut.

Mengubah pengaturan umpan tanpa harus menyimpan secara manual

Beberapa interaksi pada halaman pengaturan umpan telah ditingkatkan. Sekarang, perubahan yang Anda buat, seperti menambahkan upstream atau izin, akan langsung disimpan. Artinya, Anda tidak perlu khawatir kehilangan perubahan saat beralih antar pivot pengaturan.

Menyederhanakan autentikasi menggunakan Credential Provider lintas platform baru untuk NuGet

Berinteraksi dengan umpan NuGet yang diautentikasi menjadi jauh lebih baik. Azure Artifacts Credential Provider berbasis .NET Core baru berfungsi dengan msbuild, dotnet, dan nuget(.exe) di Windows, macOS, dan Linux. Setiap kali Anda ingin menggunakan paket dari umpan Artefak Azure, Credential Provider akan secara otomatis memperoleh dan menyimpan token atas nama klien NuGet yang Anda gunakan. Anda tidak perlu lagi menyimpan dan mengelola token secara manual dalam file konfigurasi.

Untuk mendapatkan penyedia baru, buka GitHub dan ikuti instruksi untuk klien dan platform Anda.

Mengompresi simbol saat menerbitkan ke berbagi file

Kami telah memperbarui tugas Indeks & Terbitkan Simbol untuk mendukung pemadatan simbol ketika dipublikasikan ke berbagi file.

Wiki

Menerbitkan file markdown dari repositori Git sebagai Wiki

Pengembang membuat dokumentasi untuk “API”, “SDK”, dan “dokumen bantuan yang menjelaskan kode” dalam repositori kode. Pembaca kemudian perlu menyaring kode guna menemukan dokumentasi yang tepat. Sekarang Anda cukup menerbitkan file markdown dari repositori kode dan menghostingnya di Wiki.

Dari dalam Wiki, mulailah dengan mengeklik Terbitkan kode sebagai wiki. Selanjutnya, Anda dapat menentukan folder di repositori Git yang harus dipromosikan.

Begitu Anda mengeklik Terbitkan, semua file markdown di bawah folder yang dipilih akan diterbitkan sebagai wiki. Ini juga akan memetakan kepala cabang ke wiki sehingga setiap perubahan yang Anda buat pada repositori Git akan segera diterapkan.

Lihat posting blog dokumentasi produk untuk informasi selengkapnya.

Tautan ke judul dalam halaman

Sekarang Anda dapat mengeklik ikon tautan di samping judul bagian mana pun di halaman wiki untuk membuat URL langsung ke bagian tersebut. Anda kemudian dapat menyalin URL tersebut dan membagikannya dengan anggota tim untuk menautkannya langsung ke bagian tersebut.

Melampirkan file dan gambar dalam folder

Saat mengedit halaman wiki secara offline, akan lebih mudah untuk menambahkan lampiran file dan gambar di direktori yang sama dengan halaman wiki. Sekarang, Anda dapat menambahkan lampiran atau gambar di folder apa pun di wiki dan menautkannya ke halaman Anda.

Menyematkan video di wiki

Sekarang Anda dapat menyematkan video di halaman wiki dari layanan online seperti Microsoft Stream dan YouTube. Anda dapat menambahkan URL video yang disematkan menggunakan sintaks berikut:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Mengganti nama wiki

Sekarang Anda dapat mengganti nama wiki Anda di antarmuka pengguna wiki dan menggunakan REST API. Dari menu Lainnya, klik Ganti nama wiki untuk memberi nama yang mudah diingat pada wiki Anda.

Membuka halaman di tab baru

Sekarang Anda dapat mengeklik kanan halaman wiki dan membukanya di tab baru atau cukup tekan CTRL + klik kiri pada halaman wiki untuk membukanya di tab baru.

Mempertahankan karakter khusus dalam judul halaman Wiki

Anda sekarang dapat membuat halaman wiki dengan karakter khusus seperti : < > * ? | -. Sekarang halaman dengan judul seperti “FAQ?” atau “Panduan penyiapan” dapat dibuat di Wiki. Karakter berikut diterjemahkan ke string yang dikodekan UTF-8:

Karakter	String yang Dikodekan
:	%3A
<	%3C
>	%3E
*	%2A
?	%3F
|	%7C
-	%2D

Menampilkan tautan rusak

Semua tautan di wiki yang tidak ditautkan dengan benar akan muncul dalam warna merah yang berbeda dan ikon tautan rusak, memberi Anda petunjuk visual tentang semua tautan rusak di halaman wiki.

Memperbaiki tautan rusak saat memindahkan halaman

Tautan halaman rusak adalah salah satu penyebab utama kualitas halaman yang buruk dalam solusi dokumentasi. Sebelumnya di Wiki, ketika Anda memindahkan halaman di dalam struktur pohon atau mengganti nama halaman, halaman tersebut berpotensi memutus tautan ke halaman dari halaman lain dan item kerja. Sekarang, Anda dapat memeriksa dan memperbaiki tautan sebelum rusak.

Penting

Ingatlah untuk menggunakan sintaks markdown []() untuk tautan di halaman dan jenis tautan halaman Wiki di item kerja untuk memungkinkan Wiki menemukan dan memperbaiki tautan yang berpotensi rusak ini. URL dan hyperlink teks biasa dalam item kerja tidak akan diambil oleh fitur ini.

Saat mengganti nama atau memindahkan halaman, Anda akan diminta untuk memeriksa tautan absolut atau relatif yang terpengaruh.

Anda kemudian akan melihat daftar Tautan halaman dan Item kerja yang terpengaruh sebelum mengambil tindakan.

Membuat daftar isi untuk halaman wiki

Terkadang halaman wiki bisa panjang, dengan konten yang disusun menjadi beberapa judul. Sekarang Anda dapat menambahkan daftar isi ke halaman mana pun yang memiliki setidaknya satu judul menggunakan sintaks [[_TOC_]].

Anda juga dapat menyisipkan daftar isi dengan mengeklik tombol yang sesuai di panel format saat mengedit halaman.

Lihat dokumentasi panduan markdown untuk informasi selengkapnya tentang menggunakan markdown di Azure DevOps.

Metadata tampilan untuk halaman wiki dan pratinjau kode menggunakan tag YAML

Menambahkan metadata ke dokumentasi dapat membantu pembaca dan indeks pencarian mengambil dan menampilkan konten yang bermakna. Dalam pembaruan ini, file apa pun yang berisi blok YAML di awal file akan diubah menjadi tabel metadata satu kepala dan satu baris. Blok YAML harus berbentuk set YAML yang valid antara garis putus-putus tiga. Ini mendukung semua jenis data dasar, daftar, objek sebagai nilai. Sintaks didukung di Wiki dan pratinjau file kode.

Contoh Tag YAML:

---
tag: post
title: Hello world
---

Contoh Tag YAML dengan daftar:

---
tags:
- post
- code
- web
title: Hello world
---

Menerbitkan kode sebagai wiki dengan izin Kontribusi

Sebelumnya, hanya pengguna yang memiliki izin Buat Repositori pada repositori git yang dapat menerbitkan kode sebagai wiki. Hal ini membuat administrator atau pembuat repositori menjadi hambatan bagi setiap permintaan untuk menerbitkan file markdown yang dihosting di repositori git sebagai wiki. Sekarang, Anda dapat Menerbitkan kode sebagai wiki jika hanya memiliki Izin Kontribusi pada repositori kode.

Pelaporan

Ekstensi marketplace Analytics untuk pelaporan kini tersedia

Ekstensi Analytics Marketplace sekarang tersedia untuk Azure DevOps Server. Analytics adalah masa depan pelaporan untuk Azure DevOps dan Azure DevOps Server. Menginstal ekstensi Analytics menyediakan widget tingkat lanjut, integrasi Power BI, dan akses OData.

Untuk informasi selengkapnya, lihat Apa itu Analytics dan Peta Strategi Pelaporan. Analytics ada di Pratinjau Umum. Saat ini berisi data untuk Board dan hasil Pengujian Otomatis melalui Pipelines. Lihat Data yang tersedia di Analytics Service.

Menyelidiki riwayat build melalui widget dasbor build baru

Kami memiliki widget riwayat build baru dan ditingkatkan yang dapat Anda tambahkan ke dasbor. Dengan widget ini Anda sekarang dapat menampilkan riwayat build dari cabang tertentu di dasbor dan mengonfigurasinya pada proyek publik untuk pengunjung anonim.

Penting

Jika Anda mencari wawasan tentang build XAML, terus gunakan widget yang lebih lama dan baca tentang bermigrasi dari build XAML ke build baru. Jika tidak, kami sarankan Anda pindah ke widget yang lebih baru.

---

Umpan Balik

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