Catatan Rilis Azure DevOps Server 2022

---

| Persyaratan Sistem Komunitas | Pengembang dan Persyaratan | Lisensi Kompatibilitas | DevOps Blog | SHA-256 Hash |

---

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 Server, kunjungi halaman Unduhan Server Azure DevOps.

Peningkatan langsung ke Azure DevOps Server 2022 didukung dari Azure DevOps Server 2019 atau Team Foundation Server 2015 atau yang lebih baru. Jika penyebaran TFS Anda ada di TFS 2013 atau yang lebih lama, Anda perlu melakukan beberapa langkah sementara sebelum meningkatkan ke Azure DevOps Server 2022. Silakan lihat halaman Instal untuk informasi selengkapnya.

---

Tanggal Rilis Azure DevOps Server 2022 Update 0.1 Patch 5: 14 November 2023

Catatan

Patch Azure DevOps Server bersifat kumulatif, jika Anda tidak menginstal Patch 3, patch ini menyertakan pembaruan untuk agen Azure Pipelines. Versi baru agen setelah menginstal Patch 5 adalah 3.225.0.

File	SHA-256 Hash
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

Kami telah merilis patch untuk Azure DevOps Server 2022 Update 0.1 yang menyertakan perbaikan untuk yang berikut ini.

• Memperluas daftar karakter yang diizinkan tugas PowerShell untuk validasi parameter Aktifkan argumen tugas shell.
• Perbaiki masalah yang menyebabkan pengeditan koneksi layanan persisten setelah mengklik tombol batalkan.

Tanggal Rilis Azure DevOps Server 2022 Update 0.1 Patch 4: 10 Oktober 2023

Catatan

Patch Azure DevOps Server bersifat kumulatif, jika Anda tidak menginstal Patch 3, patch ini menyertakan pembaruan untuk agen Azure Pipelines. Versi baru agen setelah menginstal Patch 5 adalah 3.225.0.

Kami telah merilis patch untuk Azure DevOps Server 2022 Update 0.1 yang menyertakan perbaikan untuk yang berikut ini.

• Memperbaiki bug yang menyebabkan alur macet dengan meningkatkan model eksekusi alur.
• Memperbaiki bug di mana identitas "Pemilik Analisis" ditampilkan sebagai Identitas Tidak Aktif pada mesin peningkatan patch.
• Pekerjaan pembersihan build berisi banyak tugas, yang masing-masing menghapus artefak untuk build. Jika salah satu tugas ini gagal, tidak ada tugas berikutnya yang berjalan. Kami mengubah perilaku ini untuk mengabaikan kegagalan tugas dan membersihkan artefak sebanyak mungkin.

Tanggal Rilis Azure DevOps Server 2022 Update 0.1 Patch 3: 12 September 2023

Catatan

Patch ini mencakup pembaruan untuk agen Azure Pipelines. Versi baru agen setelah menginstal Patch 3 adalah 3.225.0.

Kami telah merilis patch untuk Azure DevOps Server 2022 Update 0.1 yang menyertakan perbaikan untuk yang berikut ini.

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

Tanggal Rilis Azure DevOps Server 2022 Update 0.1 Patch 2: 8 Agustus 2023

Kami telah merilis patch untuk Azure DevOps Server 2022 Update 0.1 yang menyertakan perbaikan untuk yang berikut ini.

• CVE-2023-36869: Kerentanan Spoofing Server Azure DevOps.
• Memperbaiki bug dalam panggilan SOAP di mana ArithmeticException dapat dinaikkan untuk respons XML metadata besar.
• Menerapkan perubahan pada editor koneksi layanan sehingga status titik akhir memerah pada komponen dihentikan.
• Masalah yang diatasi dengan tautan relatif tidak berfungsi dalam file markdown.
• Memperbaiki masalah performa yang terkait dengan tingkat aplikasi membutuhkan waktu lebih lama dari biasanya untuk memulai ketika ada sejumlah besar tag yang ditentukan.
• Mengatasi kesalahan TF400367 pada halaman Kumpulan Agen.
• Memperbaiki bug di mana identitas Pemilik Analisis ditampilkan sebagai Identitas Tidak Aktif.
• Memperbaiki bug perulangan tak terbatas pada CronScheduleJobExtension.

Tanggal Rilis Azure DevOps Server 2022 Update 0.1 Patch 1: 13 Juni 2023

Kami telah merilis patch untuk Azure DevOps Server 2022 Update 0.1 yang menyertakan perbaikan untuk yang berikut ini.

• CVE-2023-21565: Kerentanan Spoofing Server Azure DevOps.
• CVE-2023-21569: Kerentanan Spoofing Server Azure DevOps.
• Memperbaiki bug dengan editor koneksi layanan. Sekarang draf status titik akhir diberhentikan pada komponen.
• 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 2022 Update 0.1: 9 Mei 2023

Azure DevOps Server 2022.0.1 adalah gulungan perbaikan bug. Ini mencakup semua perbaikan di Azure DevOps Server 2022.0.1 RC yang sebelumnya dirilis. Anda dapat langsung menginstal Azure DevOps Server 2022.0.1 atau meningkatkan dari Azure DevOps Server 2022 atau Team Foundation Server 2015 atau yang lebih baru.

Tanggal Rilis Azure DevOps Server 2022 Update 0.1 RC: 11 April 2023

Azure DevOps Server 2022.0.1 RC adalah gulungan perbaikan bug. Ini mencakup semua perbaikan dalam patch Azure DevOps Server 2022 yang sebelumnya dirilis. Anda dapat langsung menginstal Azure DevOps Server 2022.0.1 atau meningkatkan dari Azure DevOps Server 2022 atau Team Foundation Server 2015 atau yang lebih baru.

Rilis ini mencakup perbaikan untuk bug berikut:

• Meningkatkan Git Virtual File System (GVFS) dari ke v2.39.1.1-micorosoft.2 untuk mengatasi kerentanan keamanan.
• Data pengujian tidak dihapus, menyebabkan database bertambah. Dengan perbaikan ini, kami memperbarui retensi build untuk mencegah pembuatan data pengujian yatim piatu baru.
• Pembaruan pada AnalyticCleanupJob, status pekerjaan dihentikan dan sekarang kami melaporkan Berhasil.
• Memperbaiki perintah "penerbitan ekstensi tfx" gagal dengan kesalahan "Kunci yang diberikan tidak ada dalam kamus".
• Menerapkan solusi untuk mengatasi dan kesalahan saat mengakses ekstensi Kalender Tim.
• CVE-2023-21564: Kerentanan Pembuatan Skrip Lintas Situs Azure DevOps Server
• CVE-2023-21553: Kerentanan Eksekusi Kode Jarak Jauh Azure DevOps Server
• Memperbarui tugas MSBuild dan VSBuild untuk mendukung Visual Studio 2022.
• Perbarui metodologi pemuatan reauthentication untuk mencegah vektor serangan XSS.
• Proksi Azure DevOps Server 2022 melaporkan kesalahan berikut: VS800069: Layanan ini hanya tersedia di Azure DevOps lokal.
• Memperbaiki masalah aksesibilitas shelveset melalui UI web.
• Mengatasi masalah yang mengharuskan memulai ulang layanan tfsjobagent dan kumpulan aplikasi Azure DevOps Server setelah memperbarui pengaturan terkait SMTP di Azure DevOps Server Management Console.
• Pemberitahuan tidak dikirim selama PAT tujuh hari sebelum tanggal kedaluwarsa.

Tanggal Rilis Azure DevOps Server 2022 Patch 4: 13 Juni 2023

Kami telah merilis patch untuk Azure DevOps Server 2022 yang menyertakan perbaikan untuk yang berikut ini.

• CVE-2023-21565: Kerentanan Spoofing Server Azure DevOps.
• CVE-2023-21569: Kerentanan Spoofing Server Azure DevOps.
• Memperbaiki bug dengan editor koneksi layanan. Sekarang draf status titik akhir diberhentikan pada komponen.
• 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 2022 Patch 3: 21 Maret 2023

Kami telah merilis patch(19.205.33506.1) untuk Azure DevOps Server 2022 yang mencakup perbaikan untuk yang berikut ini.

• Mengatasi masalah yang mengharuskan memulai ulang layanan tfsjobagent dan kumpulan aplikasi Azure DevOps Server setelah memperbarui pengaturan terkait SMTP di Azure DevOps Server Management Console.
• Salin status Titik Akhir ke panel edit Titik Akhir Layanan alih-alih meneruskannya dengan referensi.
• Sebelumnya, saat mengedit koneksi layanan, pengeditan dipertahankan di UI setelah memilih tombol batalkan. Dengan patch ini, kami telah memperbaiki di Notification SDK ketika tim memiliki pengiriman pemberitahuan yang diatur ke Jangan mengirimkan. Dalam skenario ini, jika langganan pemberitahuan dikonfigurasi dengan opsi pengiriman preferensi Tim, anggota tim tidak akan menerima pemberitahuan. Tidak perlu memperluas identitas di bawah tim lebih lanjut untuk memeriksa preferensi anggota.

Tanggal Rilis Azure DevOps Server 2022 Patch 2: 14 Februari 2023

Kami telah merilis patch untuk Azure DevOps Server 2022 yang menyertakan perbaikan untuk yang berikut ini.

• CVE-2023-21564: Kerentanan Pembuatan Skrip Lintas Situs Azure DevOps Server
• Memperbarui tugas MSBuild dan VSBuild untuk mendukung Visual Studio 2022.
• Perbarui metodologi pemuatan reauthentication untuk mencegah kemungkinan vektor serangan XSS.
• Proksi Azure DevOps Server 2022 melaporkan kesalahan berikut: VS800069: Layanan ini hanya tersedia di Azure DevOps lokal.

Tanggal Rilis Azure DevOps Server 2022 Patch 1: 24 Januari 2023

Kami telah merilis patch untuk Azure DevOps Server 2022 yang menyertakan perbaikan untuk yang berikut ini.

• Data pengujian tidak dihapus, menyebabkan database bertambah. Dengan perbaikan ini, kami memperbarui retensi build untuk mencegah pembuatan data pengujian yatim piatu baru.
• Pembaruan pada AnalyticCleanupJob, status pekerjaan dihentikan dan sekarang kami melaporkan Berhasil.
• Memperbaiki perintah "penerbitan ekstensi tfx" gagal dengan kesalahan "Kunci yang diberikan tidak ada dalam kamus".
• Menerapkan solusi untuk mengatasi dan kesalahan saat mengakses ekstensi Kalender Tim.

Tanggal Rilis Azure DevOps Server 2022: 6 Desember 2022

Azure DevOps Server 2022 adalah gulungan perbaikan bug. Ini termasuk semua fitur di Azure DevOps Server 2022 RC2 dan RC1 yang sebelumnya dirilis.

Tanggal Rilis Azure DevOps Server 2022 RC2: 25 Oktober 2022

Azure DevOps Server 2022 RC2 adalah gulungan perbaikan bug. Ini termasuk semua fitur di Azure DevOps Server 2022 RC1 yang sebelumnya dirilis.

Catatan

Algoritma RSA SSH Baru Diaktifkan

Dukungan kunci publik RSA telah ditingkatkan untuk mendukung jenis kunci umum SHA2 selain SHA1 SSH-RSA yang sebelumnya kami dukung.

Sekarang jenis kunci publik yang didukung meliputi:

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Tindakan Diperlukan

Jika Anda menerapkan pekerjaan untuk mengaktifkan SSH-RSA dengan secara eksplisit menentukannya dalam .ssh/config1 file, Anda harus menghapus PubkeyAcceptedTypes, atau memodifikasinya untuk menggunakan RSA-SHA2-256, atau RSA-SHA2-512, atau keduanya. Anda dapat menemukan detail tentang apa yang harus dilakukan jika Anda masih dimintai kata sandi Anda dan GIT_SSH_COMMAND="ssh -v" git fetch tidak menunjukkan algoritma tanda tangan bersama dalam dokumentasi di sini.

Dukungan kunci elips belum ditambahkan dan tetap menjadi fitur yang sangat diminta di backlog kami.

Tanggal Rilis Azure DevOps Server 2022 RC1: 9 Agustus 2022

Ringkasan Apa yang Baru di Azure DevOps Server 2022

Penting

Layanan Gudang dan Analisis tidak digunakan lagi di versi Azure DevOps Server (2020) sebelumnya. Di Azure DevOps Server 2022, Layanan Gudang dan Analisis telah dihapus dari produk. Analytics sekarang memberikan pengalaman pelaporan dalam produk.

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

• Paket Pengiriman
• Menampilkan persona yang benar pada tautan penerapan
• Kontrol baru untuk variabel lingkungan dalam alur
• Menghasilkan token tidak terbatas untuk build fork
• Halaman TFVC baru
• Grup Menurut Tag yang tersedia di widget bagan

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

• Papan
• Repositori
• Pipelines
• Pelaporan

---

Boards

Paket Pengiriman

Kami sangat senang mengumumkan bahwa Paket Pengiriman sekarang disertakan dalam Azure DevOps Server. Paket Pengiriman memberikan 3 skenario utama:

• Ringkasan waktu paket
• Kemajuan pekerjaan
• Pelacakan Dependensi

Di bawah ini adalah fitur utama. Pemfilteran, Penanda, dan Kriteria Bidang juga merupakan bagian dari Paket Pengiriman.

Ada dua tampilan utama: ringkas dan diperluas

Paket Pengiriman 2.0 memungkinkan menampilkan semua item kerja dalam paket Anda pada garis waktu, menggunakan tanggal mulai dan target atau tanggal perulangan. Urutan prioritas adalah tanggal mulai & target kemudian diikuti dengan iterasi. Ini memungkinkan Anda menambahkan item kerja tingkat portofolio sepertiEpic yang sering tidak didefinisikan ke perulangan.

Ada dua tampilan utama tampilan ringkas dan tampilan yang diperluas. Anda juga dapat memperbesar dan memperkecil paket dengan mengeklik kaca pembesar di sisi kanan atas rencana.

Ada dua tampilan utama tampilan ringkas dan tampilan yang diperluas. Anda juga dapat memperbesar dan memperkecil paket dengan mengklik kaca pembesar di sisi kanan paket.

• Tampilan Ringkas

  Tampilan ringkas menunjukkan semua kartu item kerja diciutkan yang berarti bahwa tidak semua informasi kartu ditampilkan. Tampilan ini berguna untuk tampilan keseluruhan pekerjaan dalam paket. Untuk menciutkan bidang kartu, klik ikon kartu di samping ikon pembesar di sisi kanan paket.

  Berikut adalah contoh rencana yang beralih antara tampilan yang ringkas dan diperluas.

  

• Tampilan diperluas

  Tampilan yang diperluas memperlihatkan kemajuan item kerja dengan menghitung jumlah anak dan item tertaut dan memperlihatkan persentase selesai. Kemajuan saat ini ditentukan oleh jumlah item kerja.

  Berikut adalah contoh paket menggunakan tampilan yang diperluas. Perhatikan bilah kemajuan dan persentase selesai.

  

Pelacakan Dependensi

Pelacakan dependensi didasarkan pada tautan pendahulu dan penerus yang didefinisikan dalam item kerja. Jika tautan tersebut tidak ditentukan, maka tidak ada baris dependensi yang akan ditampilkan. Ketika ada masalah dependensi dengan item kerja, ikon tautan dependensi berwarna merah.

• Menampilkan Dependensi

  Dependensi tertentu dilihat melalui panel dependensi yang menunjukkan semua dependensi untuk item kerja tersebut, termasuk arahnya. Tanda seru merah menunjukkan masalah dependensi. Untuk memunculkan panel, cukup klik ikon tautan dependensi di sudut kanan atas kartu. Berikut adalah contoh dependensi.

  

  

• Baris Dependensi

  Dependensi antara item kerja divisualisasikan dengan garis panah arah antara item kerja masing-masing. Beberapa dependensi akan ditampilkan sebagai beberapa baris. Garis berwarna merah menunjukkan masalah.

  Berikut adalah beberapa contoh.

  

  Berikut adalah contoh item kerja dengan beberapa dependensi dan juga berfungsi menggunakan tampilan ringkas.

  

  Ketika ada masalah, warna garis berwarna merah, dan begitu juga ikon dependensi.

  Berikut adalah contohnya.

  

Gaya Kartu

Kartu sekarang dapat ditata menggunakan aturan, seperti papan Kanban. Buka pengaturan paket dan klik Gaya. Di panel Gaya klik + Tambahkan aturan gaya untuk menambahkan aturan lalu klik Simpan. Mungkin ada hingga 10 aturan dan setiap aturan dapat memiliki hingga 5 klausa.

• Sebelumnya

• Sesudahnya

Untuk mempelajari selengkapnya tentang Paket Pengiriman, lihat dokumentasi di sini.

Item yang dihapus di Hub Item Kerja

Hub Item Kerja adalah tempat untuk melihat daftar item yang Anda buat atau yang ditetapkan untuk Anda. Ini menyediakan beberapa fungsi pivot dan filter yang dipersonalisasi untuk menyederhanakan daftar item kerja. Salah satu keluhan teratas dari pivot Ditetapkan ke saya adalah bahwa ia menampilkan item kerja yang dihapus. Kami setuju bahwa item kerja yang dihapus tidak lagi bernilai dan tidak boleh berada di backlog. Dalam sprint ini, kami menyembunyikan semua item yang Dihapus dari tampilan Ditetapkan untuk saya di Hub Item Kerja.

Menampilkan persona yang benar pada tautan penerapan

Bagian pengembangan dalam item kerja menunjukkan daftar penerapan dan permintaan pull yang relevan. Anda dapat melihat penulis permintaan penerapan atau pull bersama dengan waktu terkait. Dengan pembaruan ini, kami memperbaiki masalah dengan avatar penulis yang ditampilkan dengan tidak benar dalam tampilan.

Menghapus kemampuan untuk mengunduh lampiran yang dihapus dari riwayat item kerja

Kami memperbaiki masalah kecil di mana pengguna dapat mengunduh lampiran dari riwayat item kerja, bahkan setelah lampiran dihapus dari formulir. Sekarang, setelah lampiran dihapus, lampiran tidak dapat diunduh dari riwayat, url unduhan juga tidak akan tersedia dari respons REST API.

Menambahkan nilai "Tidak Akan Memperbaiki" ke bidang Alasan bug

Seperti semua jenis item kerja lainnya, jenis item kerja Bug memiliki alur kerja yang terdefinisi dengan baik. Setiap alur kerja terdiri dari tiga Status atau lebih dan Alasan. Alasan menentukan mengapa item ditransisikan dari satu Status ke Status lainnya. Dengan pembaruan ini, kami menambahkan nilai Tidak akan memperbaiki nilai alasan untuk jenis item kerja Bug dalam proses Agile. Nilai akan tersedia sebagai alasan saat memindahkan Bug dari Baru atau Aktif ke Diselesaikan. Anda dapat mempelajari selengkapnya tentang cara menentukan, mengambil, melakukan triase, dan mengelola bug perangkat lunak dalam dokumentasi Azure Boards.

Pipelines

Penghapusan kebijakan retensi per alur dalam build klasik

Anda sekarang dapat mengonfigurasi kebijakan retensi untuk build klasik dan alur YAML di pengaturan proyek Azure DevOps. Aturan retensi per alur untuk alur build klasik tidak lagi didukung. Meskipun ini adalah satu-satunya cara untuk mengonfigurasi retensi untuk alur YAML, Anda juga dapat mengonfigurasi retensi untuk alur build klasik berdasarkan per alur. Kami menghapus semua aturan retensi per alur untuk alur build klasik dalam rilis mendatang.

Apa artinya ini bagi Anda: alur build klasik apa pun yang digunakan untuk memiliki aturan retensi per alur akan diatur oleh aturan retensi tingkat proyek.

Untuk memastikan Anda tidak kehilangan build apa pun saat meningkatkan, kami akan membuat sewa untuk semua build yang ada pada saat peningkatan yang tidak memiliki sewa.

Kami sarankan Anda memeriksa pengaturan retensi tingkat proyek setelah peningkatan. Jika alur Anda secara khusus memerlukan aturan kustom, Anda dapat menggunakan tugas kustom di alur Anda. Untuk informasi tentang menambahkan sewa retensi melalui tugas, lihat dokumentasi kebijakan retensi yang ditetapkan untuk build, rilis, dan pengujian.

Kontrol baru untuk variabel lingkungan dalam alur

Agen Azure Pipelines memindai output standar untuk perintah pengelogan khusus dan menjalankannya. Perintah setVariable dapat digunakan untuk mengatur variabel atau memodifikasi variabel yang ditentukan sebelumnya. Ini berpotensi dieksploitasi oleh aktor di luar sistem. Misalnya, jika alur Anda memiliki langkah yang mencetak daftar file di server ftp, maka seseorang dengan akses ke server ftp dapat menambahkan file baru, yang namanya berisi setVariable perintah dan menyebabkan alur mengubah perilakunya.

Kami memiliki banyak pengguna yang mengandalkan pengaturan variabel menggunakan perintah pengelogan di alur mereka. Dengan rilis ini, kami membuat perubahan berikut untuk mengurangi risiko penggunaan perintah yang setVariable tidak diinginkan.

• Kami telah menambahkan konstruksi baru untuk penulis tugas. Dengan menyertakan cuplikan seperti berikut ini di task.json, penulis tugas dapat mengontrol apakah ada variabel yang diatur oleh tugas mereka.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Selain itu, kami memperbarui sejumlah tugas bawaan seperti ssh sehingga tidak dapat dieksploitasi.

• Terakhir, Anda sekarang dapat menggunakan konstruksi YAML untuk mengontrol apakah langkah dapat mengatur variabel.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Menghasilkan token tidak terbatas untuk build fork

Pengguna GitHub Enterprise biasanya menggunakan fork untuk berkontribusi pada repositori hulu. Ketika Azure Pipelines membangun kontribusi dari fork repositori GitHub Enterprise, Azure Pipelines membatasi izin yang diberikan ke token akses pekerjaan dan tidak mengizinkan rahasia alur diakses oleh pekerjaan tersebut. Anda dapat menemukan informasi selengkapnya tentang keamanan membangun fork dalam dokumentasi kami.

Ini mungkin lebih ketat daripada yang diinginkan di lingkungan tertutup seperti itu, di mana pengguna mungkin masih mendapat manfaat dari model kolaborasi sumber dalam. Meskipun Anda dapat mengonfigurasi pengaturan dalam alur untuk membuat rahasia tersedia untuk fork, tidak ada pengaturan untuk mengontrol cakupan token akses pekerjaan. Dengan rilis ini, kami memberi Anda kontrol untuk menghasilkan token akses pekerjaan reguler bahkan untuk build fork.

Anda dapat mengubah pengaturan ini dari Pemicu di editor alur. Sebelum mengubah pengaturan ini, pastikan Anda sepenuhnya memahami implikasi keamanan untuk mengaktifkan konfigurasi ini.

Repos sebagai sumber daya yang dilindungi dalam alur YAML

Anda dapat mengatur proyek Azure DevOps Anda untuk menghosting banyak sub-proyek - masing-masing dengan repositori Azure DevOps Git sendiri dan satu atau beberapa alur. Dalam struktur ini, Anda mungkin ingin mengontrol alur mana yang dapat mengakses repositori mana. Misalnya, katakanlah Anda memiliki dua repositori A dan B dalam proyek yang sama dan dua alur X dan Y yang biasanya membangun repositori ini. Anda mungkin ingin mencegah alur Y mengakses repositori A. Secara umum, Anda ingin kontributor A mengontrol alur mana yang ingin mereka berikan aksesnya.

Meskipun ini sebagian dimungkinkan dengan repositori dan alur Azure Git, tidak ada pengalaman untuk mengelolanya. Fitur ini membahas kesenjangan tersebut. Repositori Azure Git sekarang dapat diperlakukan sebagai sumber daya yang dilindungi dalam alur YAML, sama seperti koneksi layanan dan kumpulan agen.

Sebagai kontributor repositori A, Anda dapat menambahkan pemeriksaan dan izin alur ke repositori Anda. Untuk melakukan ini, navigasikan ke pengaturan proyek, pilih Repositori, lalu repositori Anda. Anda akan melihat menu baru yang disebut "Pemeriksaan", di mana Anda dapat mengonfigurasi salah satu pemeriksaan dalam kotak atau kustom dalam bentuk fungsi Azure.

Di bawah tab "Keamanan", Anda dapat mengelola daftar alur yang dapat mengakses repositori.

Setiap kali alur YAML menggunakan repositori, infrastruktur Azure Pipelines memverifikasi dan memastikan bahwa semua pemeriksaan dan izin terpenuhi.

Catatan

Izin dan pemeriksaan ini hanya berlaku untuk alur YAML. Alur klasik tidak mengenali fitur baru ini.

Izin dan pemeriksaan pada grup variabel dan file aman

Anda dapat menggunakan berbagai jenis sumber daya bersama di alur YAML. Contohnya termasuk koneksi layanan, grup variabel, file aman, kumpulan agen, lingkungan, atau repositori. Untuk melindungi alur agar tidak mengakses sumber daya, pemilik sumber daya dapat mengonfigurasi izin dan memeriksa sumber daya tersebut. Setiap kali alur mencoba mengakses sumber daya, semua izin dan pemeriksaan yang dikonfigurasi dievaluasi. Perlindungan ini telah tersedia pada koneksi layanan, lingkungan, dan kumpulan agen untuk sementara waktu. Mereka baru-baru ini ditambahkan ke repositori. Dengan rilis ini, kami menambahkan perlindungan yang sama ke grup variabel dan file aman.

Untuk membatasi akses ke grup variabel atau file aman ke sekumpulan kecil alur, gunakan fitur izin Alur.

Untuk mengonfigurasi pemeriksaan atau persetujuan yang harus dievaluasi setiap kali alur berjalan, gunakan fitur Persetujuan dan periksa untuk Pustaka .

Perubahan dalam pembuatan lingkungan otomatis

Saat Anda menulis alur YAML dan merujuk ke lingkungan yang tidak ada, Azure Pipelines secara otomatis membuat lingkungan. Pembuatan otomatis ini dapat terjadi dalam konteks pengguna atau konteks sistem. Dalam alur berikut, Azure Pipelines tahu tentang pengguna yang melakukan operasi:

• Anda menggunakan wizard pembuatan alur YAML di pengalaman web Azure Pipelines dan merujuk ke lingkungan yang belum dibuat.
• Anda memperbarui file YAML menggunakan editor web Azure Pipelines dan menyimpan alur setelah menambahkan referensi ke lingkungan yang tidak ada. Dalam setiap kasus di atas, Azure Pipelines memiliki pemahaman yang jelas tentang pengguna yang melakukan operasi. Oleh karena itu, ia membuat lingkungan dan menambahkan pengguna ke peran administrator untuk lingkungan. Pengguna ini memiliki semua izin untuk mengelola lingkungan dan/atau menyertakan pengguna lain dalam berbagai peran untuk mengelola lingkungan.

Dalam alur berikut, Azure Pipelines tidak memiliki informasi tentang pengguna yang membuat lingkungan: Anda memperbarui file YAML menggunakan editor kode eksternal lain, menambahkan referensi ke lingkungan yang tidak ada, lalu menyebabkan alur integrasi berkelanjutan dipicu. Dalam hal ini, Azure Pipelines tidak tahu tentang pengguna. Sebelumnya, kami menangani kasus ini dengan menambahkan semua kontributor proyek ke peran administrator lingkungan. Setiap anggota proyek kemudian dapat mengubah izin ini dan mencegah orang lain mengakses lingkungan.

Kami menerima umpan balik Anda tentang memberikan izin administrator pada lingkungan kepada semua anggota proyek. Saat kami mendengarkan umpan balik Anda, kami mendengar bahwa kami tidak boleh membuat lingkungan secara otomatis jika tidak jelas siapa pengguna yang melakukan operasi tersebut. Dengan rilis ini, kami membuat perubahan pada bagaimana lingkungan akan dibuat secara otomatis:

• Ke depannya, eksekusi alur tidak akan secara otomatis membuat lingkungan jika tidak ada dan jika konteks pengguna tidak diketahui. Dalam kasus seperti itu, alur akan gagal dengan kesalahan Lingkungan yang tidak ditemukan. Anda perlu membuat lingkungan terlebih dahulu dengan keamanan yang tepat dan memeriksa konfigurasi sebelum menggunakannya dalam alur.
• Alur dengan konteks pengguna yang diketahui masih akan membuat lingkungan secara otomatis seperti yang mereka lakukan di masa lalu.
• Terakhir, perlu dicatat bahwa fitur untuk membuat lingkungan secara otomatis hanya ditambahkan untuk menyederhanakan proses memulai azure Pipelines. Itu dimaksudkan untuk skenario pengujian, dan bukan untuk skenario produksi. Anda harus selalu membuat lingkungan produksi terlebih dahulu dengan izin dan pemeriksaan yang tepat, lalu menggunakannya dalam alur.

Menghapus dialog Wawasan dari Alur Build

Berdasarkan umpan balik Anda, kotak dialog wawasan tugas/alur yang ditampilkan saat menavigasi Alur Build telah dihapus untuk meningkatkan alur kerja. Analitik alur masih tersedia sehingga Anda memiliki wawasan yang Anda butuhkan.

Dukungan untuk penyebaran berurutan daripada yang terbaru hanya saat menggunakan pemeriksaan kunci eksklusif

Dalam alur YAML, pemeriksaan digunakan untuk mengontrol eksekusi tahapan pada sumber daya yang dilindungi. Salah satu pemeriksaan umum yang dapat Anda gunakan adalah pemeriksaan kunci eksklusif. Pemeriksaan ini memungkinkan hanya satu eksekusi dari alur yang dilanjutkan. Ketika beberapa eksekusi mencoba menyebarkan ke lingkungan secara bersamaan, pemeriksaan membatalkan semua eksekusi lama dan mengizinkan eksekusi terbaru untuk disebarkan.

Membatalkan eksekusi lama adalah pendekatan yang baik ketika rilis Anda bersifat kumulatif dan berisi semua perubahan kode dari eksekusi sebelumnya. Namun, ada beberapa alur di mana perubahan kode tidak kumulatif. Dengan fitur baru ini, Anda dapat memilih untuk mengizinkan semua eksekusi untuk melanjutkan dan menyebarkan secara berurutan ke lingkungan, atau mempertahankan perilaku sebelumnya untuk membatalkan eksekusi lama dan hanya mengizinkan yang terbaru. Anda dapat menentukan perilaku ini menggunakan properti baru yang disebut lockBehavior dalam file YAML alur. Nilai sequential menyiratkan bahwa semua eksekusi memperoleh kunci secara berurutan ke sumber daya yang dilindungi. Nilai runLatest menyiratkan bahwa hanya eksekusi terbaru yang memperoleh kunci ke sumber daya.

Untuk menggunakan pemeriksaan kunci eksklusif dengan sequential penyebaran atau runLatest, ikuti langkah-langkah berikut:

1. Aktifkan pemeriksaan kunci eksklusif pada lingkungan (atau sumber daya lain yang dilindungi).
2. Dalam file YAML untuk alur, tentukan properti baru yang disebut lockBehavior. Ini dapat ditentukan untuk seluruh alur atau untuk tahap tertentu:

Atur pada panggung:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Atur pada alur:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Jika Anda tidak menentukan lockBehavior, itu diasumsikan sebagai runLatest.

Dukungan untuk ServiceNow versi Quebec

Azure Pipelines memiliki integrasi yang sudah ada dengan ServiceNow. Integrasi bergantung pada aplikasi di ServiceNow dan ekstensi di Azure DevOps. Kami sekarang telah memperbarui aplikasi untuk bekerja dengan versi Quebec ServiceNow. Alur klasik dan YAML sekarang berfungsi dengan Quebec. Untuk memastikan bahwa integrasi ini berfungsi, tingkatkan ke versi baru aplikasi (4.188.0) dari penyimpanan Service Now. Untuk informasi selengkapnya, lihat Mengintegrasikan dengan ServiceNow Change Management.

Ekspresi bersyarjana YAML baru

Menulis ekspresi bersyarah dalam file YAML menjadi lebih mudah dengan penggunaan ${{ else }} dan ${{ elseif }} ekspresi. Di bawah ini adalah contoh cara menggunakan ekspresi ini dalam file alur YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Dukungan untuk kartubebas dalam filter jalur

Kartubebas dapat digunakan saat menentukan cabang inklusi dan pengecualian untuk pemicu CI atau PR dalam file YAML alur. Namun, mereka tidak dapat digunakan saat menentukan filter jalur. Misalnya, Anda tidak dapat menyertakan semua jalur yang cocok src/app/**/myapp*. Ini telah dinyatakan sebagai ketidaknyamanan oleh beberapa pelanggan. Pembaruan ini mengisi kesenjangan ini. Sekarang, Anda dapat menggunakan karakter wild card (**, *, atau ?) saat menentukan filter jalur.

Spesifikasi agen default untuk alur adalah Windows-2022

Gambar windows-2022 siap menjadi versi default untuk windows-latest label di agen yang dihosting Microsoft Azure Pipelines. Hingga saat ini, label ini menunjuk ke agen windows-2019. Perubahan ini akan diluncurkan selama periode beberapa minggu yang dimulai pada 17 Januari. Kami berencana untuk menyelesaikan migrasi pada bulan Maret.

Azure Pipelines telah mendukung windows-2022 sejak September 2021. Kami telah memantau umpan balik Anda untuk meningkatkan windows-2022 stabilitas gambar dan sekarang kami siap untuk mengaturnya sebagai yang terbaru.

Gambar ini windows-2022 mencakup Visual Studio 2022. Untuk daftar lengkap perbedaan antara windows-2022 dan windows-2019, kunjungi masalah GitHub. Untuk daftar lengkap perangkat lunak yang diinstal pada gambar, periksa di sini.

Folder alur mengganti nama memvalidasi izin

Folder yang berisi alur dapat diganti namanya. Mengganti nama folder sekarang akan berhasil hanya jika pengguna memiliki izin edit pada setidaknya satu alur yang terkandung dalam folder.

Perencanaan peningkatan runtime Agen Alur

Apa itu Agen Alur?

Agen Alur Azure DevOps adalah produk perangkat lunak yang berjalan pada host alur untuk menjalankan pekerjaan alur. Ini berjalan pada agen yang dihosting Microsoft, agen Set Skala, dan agen yang dihost sendiri. Dalam kasus terakhir, Anda menginstalnya sendiri. Agen Alur terdiri dari Listener dan Worker (diimplementasikan dalam .NET), Pekerja menjalankan tugas yang diimplementasikan baik di Node atau PowerShell dan oleh karena itu menghosting runtime tersebut untuk mereka.

Peningkatan yang akan datang ke penghentian .NET 6 & Red Hat 6

Dengan rilis .NET 6 , kami dapat memanfaatkan kemampuan lintas platform barunya. Secara khusus, kita akan dapat memberikan kompatibilitas asli untuk Apple Silicon dan Windows Arm64. Oleh karena itu kami berencana untuk pindah ke .NET 6 untuk Agen Alur (Listener dan Pekerja) dalam beberapa bulan mendatang.

Karena sejumlah kendala yang diberlakukan ini, kami menghilangkan dukungan Red Hat Enterprise Linux 6 dari agen kami 30 April 2022.

Pembaruan untuk tugas Penyalinan File Azure

Kami meluncurkan versi baru tugas Azure File Copy. Tugas ini digunakan untuk menyalin file ke blob penyimpanan Microsoft Azure atau komputer virtual (VM). Versi baru memiliki beberapa pembaruan yang sering diminta oleh komunitas:

• Versi alat AzCopy telah diperbarui ke 10.12.2, yang memiliki dukungan untuk jenis konten file. Akibatnya, ketika Anda menyalin PDF, Excel, PPT, atau salah satu jenis mime yang didukung, jenis konten file diatur dengan benar.

• Dengan versi baru AzCopy, Anda juga dapat mengonfigurasi pengaturan untuk membersihkan target saat jenis tujuan adalah Azure Blob. Mengatur opsi ini akan menghapus semua folder/file dalam kontainer tersebut. Atau jika awalan blob disediakan, semua folder/file dalam awalan tersebut akan dihapus.

• Versi baru tugas bergantung pada modul Az yang diinstal pada agen alih-alih modul AzureRM. Ini akan menghapus peringatan yang tidak perlu dalam beberapa kasus saat menggunakan tugas.

Perubahan adalah bagian dari pembaruan versi utama untuk tugas ini. Anda harus secara eksplisit memperbarui alur Anda untuk menggunakan versi baru. Kami membuat pilihan ini untuk memperbarui versi utama untuk memastikan bahwa kami tidak merusak alur apa pun yang masih bergantung pada modul AzureRM.

Titik ekstensi baru untuk tampilan detail Alur

Kami telah menambahkan dua titik ekstensibilitas baru yang dapat Anda targetkan di ekstensi Anda. Titik ekstensibilitas ini memungkinkan Anda menambahkan tombol kustom di header alur dan menu kustom pada folder alur:

• Tombol kustom di header alur: ms.vss-build-web.pipelines-header-menu
• Menu kustom pada folder alur: ms.vss-build-web.pipelines-folder-menu

Untuk menggunakan titik ekstensibilitas baru ini, cukup tambahkan kontribusi baru yang menargetkannya dalam file manifes ekstensi vss-extension.json Azure DevOps Anda.

Contohnya:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Hasilnya adalah:

• Tombol kustom di header alur

  

• Menu kustom pada folder alur

  

Peningkatan migrasi ke Layanan Azure DevOps

Saat menjalankan impor dari Azure DevOps Server ke Azure DevOps Services, Anda harus mempertimbangkan bahwa Azure DevOps tidak lagi mendukung aturan retensi per alur. Dengan pembaruan ini, kami menghapus kebijakan ini saat Anda bermigrasi ke Azure DevOps Services dari Azure DevOps Server lokal Anda. Untuk mempelajari selengkapnya tentang mengonfigurasi kebijakan retensi, lihat dokumentasi kami tentang pengaturan kebijakan retensi untuk build, rilis, dan pengujian.

Penyempurnaan alur menjalankan REST API

Sebelumnya, Pipelines Runs REST API hanya mengembalikan repositori self . Dengan pembaruan ini, Pipelines Runs REST API mengembalikan semua sumber daya repositori build.

Templat Alur YAML yang diperluas sekarang dapat diteruskan informasi konteks untuk tahapan, pekerjaan, dan penyebaran

Dengan pembaruan ini, kami menambahkan properti baru templateContext untuk jobkomponen alur , , deploymentdan stage YAML yang dimaksudkan untuk digunakan bersama dengan templat.

Berikut adalah skenario untuk menggunakan templateContext:

• Anda menggunakan templat untuk mengurangi duplikasi kode atau untuk meningkatkan keamanan alur Anda

• Templat Anda mengambil sebagai parameter daftar stages, , jobsatau deployments

• Templat memproses daftar input dan melakukan beberapa transformasi pada setiap tahap, pekerjaan, atau penyebaran. Misalnya, ini mengatur lingkungan tempat setiap pekerjaan berjalan atau menambahkan langkah-langkah tambahan untuk memberlakukan kepatuhan

• Pemrosesan memerlukan informasi tambahan untuk diteruskan oleh penulis alur ke dalam templat untuk setiap tahap, pekerjaan, atau penyebaran dalam daftar

Mari lihat contohnya. Katakanlah Anda menulis alur yang menjalankan pengujian end-to-end untuk validasi permintaan pull. Tujuan Anda adalah menguji hanya satu komponen sistem Anda, tetapi, karena Anda berencana untuk menjalankan pengujian end-to-end, Anda memerlukan lingkungan di mana lebih banyak komponen sistem tersedia, dan Anda perlu menentukan perilakunya.

Anda menyadari tim lain akan memiliki kebutuhan yang sama, jadi Anda memutuskan untuk mengekstrak langkah-langkah untuk menyiapkan lingkungan ke dalam templat. Kodenya terlihat seperti berikut:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Apa yang dilakukan templat, untuk setiap pekerjaan dalam testSet parameter, templat mengatur respons komponen sistem yang ditentukan oleh ${{ testJob.templateContext.requiredComponents }} untuk mengembalikan ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Kemudian, Anda dapat membuat alur Anda sendiri yang meluas testing-template.yml seperti dalam contoh berikut.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Alur ini menjalankan dua tes, positif dan negatif. Kedua pengujian mengharuskan dimensionsapi komponen tersedia. Pekerjaan positive_test mengharapkan dimensionsapi kode HTTP pengembalian 200, sementara negative_test mengharapkannya mengembalikan kode HTTP 500.

Mendukung Akun Layanan Terkelola Grup sebagai akun layanan agen

Agen Azure Pipelines sekarang mendukung Akun Layanan Terkelola Grup pada agen yang dihost sendiri di Windows.

Akun Layanan Terkelola Grup menyediakan manajemen kata sandi terpusat untuk akun domain yang bertindak sebagai akun layanan. Agen Azure Pipelines dapat mengenali jenis akun ini sehingga kata sandi tidak diperlukan selama konfigurasi:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Eksekusi informasi

Eksekusi informasi memberi tahu Anda Azure DevOps gagal mengambil kode sumber alur YAML. Eksekusi seperti itu terlihat seperti berikut ini.

Azure DevOps mengambil kode sumber alur YAML sebagai respons terhadap peristiwa eksternal, misalnya, penerapan yang didorong, atau sebagai respons terhadap pemicu internal, misalnya, untuk memeriksa apakah ada perubahan kode dan memulai eksekusi terjadwal atau tidak. Ketika langkah ini gagal, sistem membuat eksekusi informasi. Eksekusi ini dibuat hanya jika kode alur berada di repositori GitHub atau BitBucket.

Mengambil kode YAML alur dapat gagal karena:

• Penyedia repositori mengalami pemadaman
• Minta pembatasan
• Masalah autentikasi
• Tidak dapat mengambil konten file .yml alur

Baca selengkapnya tentang eksekusi Informasi.

Properti REST API retentionRules Definisi Build sudah usang

Dalam jenis respons BUILD Definition REST APIBuildDefinition, retentionRules properti sekarang ditandai sebagai usang, karena properti ini selalu mengembalikan set kosong.

Repositori

Halaman TFVC baru

Kami telah memperbarui berbagai halaman di Azure DevOps untuk menggunakan platform web baru dengan tujuan membuat pengalaman lebih konsisten dan lebih mudah diakses di berbagai layanan. Halaman TFVC telah diperbarui untuk menggunakan platform web baru. Dengan versi ini, kami membuat halaman TFVC baru tersedia secara umum.

Menonaktifkan repositori

Pelanggan sering meminta cara untuk menonaktifkan repositori dan mencegah pengguna mengakses kontennya. Misalnya, Anda mungkin ingin melakukan ini saat:

• Anda menemukan rahasia di repositori.
• Alat pemindaian pihak ketiga menemukan repositori tidak patuh.

Dalam kasus seperti itu, Anda mungkin ingin menonaktifkan repositori untuk sementara waktu saat Anda bekerja untuk mengatasi masalah tersebut. Dengan pembaruan ini, Anda dapat menonaktifkan repositori jika Anda memiliki izin Hapus repositori . Dengan menonaktifkan repositori, Anda:

• Dapat mencantumkan repositori dalam daftar repositori
• Tidak dapat membaca isi repositori
• Tidak dapat memperbarui isi repositori
• Lihat pesan bahwa repositori telah dinonaktifkan saat mereka mencoba mengakses repositori di antarmuka pengguna Azure Repos

Setelah langkah-langkah mitigasi yang diperlukan diambil, pengguna dengan izin Repositori Hapus dapat mengaktifkan kembali repositori. Untuk menonaktifkan atau mengaktifkan repositori, buka Pengaturan Proyek, pilih Repositori, lalu repositori tertentu.

Mengonfigurasi pembuat cabang untuk tidak mendapatkan "Kelola izin" di cabang mereka

Saat membuat cabang baru, Anda mendapatkan "Kelola izin" di cabang tersebut. Izin ini memungkinkan Anda mengubah izin pengguna lain atau mengakui pengguna tambahan untuk berkontribusi ke cabang tersebut. Misalnya, pembuat cabang dapat menggunakan izin ini untuk memungkinkan pengguna eksternal lain membuat perubahan pada kode. Atau, mereka dapat mengizinkan alur (membangun identitas layanan) untuk mengubah kode di cabang tersebut. Dalam proyek tertentu dengan persyaratan kepatuhan yang lebih tinggi, pengguna seharusnya tidak dapat membuat perubahan tersebut.

Dengan pembaruan ini, Anda dapat mengonfigurasi setiap dan semua repositori dalam proyek tim Anda dan membatasi pembuat cabang untuk mendapatkan izin "Kelola izin". Untuk melakukan ini, navigasikan ke pengaturan proyek, pilih Repositori, lalu Pengaturan untuk semua repositori atau repositori tertentu.

Pengaturan ini aktif secara default untuk menimpa perilaku yang ada. Tapi, Anda dapat menonaktifkannya jika Anda ingin menggunakan fitur keamanan baru ini.

Mencegah pengguna fork untuk memilih pada PR upstream mereka

Dengan Azure Repos, pengguna dengan izin "baca" pada repositori dapat membuat fork repositori dan membuat perubahan di fork mereka. Untuk mengirimkan permintaan pull dengan perubahan mereka ke upstream, pengguna perlu izin "berkontribusi pada permintaan pull" di upstream. Namun, izin ini juga mengatur siapa yang dapat memilih permintaan pull di repositori hulu. Akibatnya, Anda dapat berakhir dalam situasi di mana pengguna, yang bukan kontributor ke repositori, dapat mengirimkan permintaan pull dan menyebabkannya digabungkan tergantung pada cara Anda menyiapkan kebijakan cabang.

Dalam proyek yang mempromosikan model sumber dalam, fork-and-contribute adalah pola umum. Untuk mengamankan dan mempromosikan pola ini lebih lanjut, kami mengubah izin untuk memilih permintaan pull dari "berkontribusi terhadap permintaan pull" menjadi "berkontribusi". Namun, perubahan ini tidak dilakukan secara default di semua proyek. Anda harus ikut serta dan memilih kebijakan baru di repositori Anda, yang disebut "Mode Pemungutan Suara Ketat" untuk mengalihkan izin ini. Sebaiknya Anda melakukannya jika Anda mengandalkan fork di Azure Repos.

Pelaporan

Grup Menurut Tag yang tersedia di widget bagan

Widget bagan Grup Menurut Tag sekarang tersedia secara default untuk semua pelanggan. Saat menggunakan widget bagan, sekarang ada opsi yang tersedia untuk tag. Pengguna dapat memvisualisasikan informasi mereka dengan memilih semua tag atau sekumpulan tag di widget.

Menampilkan jenis item kerja kustom di widget burndown

Sebelumnya, Anda tidak dapat melihat jenis item kerja kustom yang dikonfigurasi dalam widget burn down dan dijumlahkan atau dihitung oleh bidang kustom. Dengan pembaruan ini, kami memperbaiki masalah ini dan sekarang Anda dapat melihat jenis item kerja kustom di widget burndown.

---

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