Catatan Rilis pembaruan 1 Azure DevOps Server 2022

---

| Komunitas | PengembangPersyaratan dan Kompatibilitas | SistemKetentuan | LisensiBlog | DevOpsHash SHA-256 |

---

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

Untuk mempelajari selengkapnya tentang menginstal atau meningkatkan penyebaran Azure DevOps Server, lihat Azure DevOps Server Persyaratan.

Untuk mengunduh produk Azure DevOps Server, kunjungi halaman Unduhan Azure DevOps Server.

Peningkatan langsung ke Azure DevOps Server 2022 Pembaruan 1 didukung dari Azure DevOps Server 2019 atau Team Foundation Server 2015 atau yang lebih baru. Jika penyebaran TFS Anda berada 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 lebih lanjut.

---

Azure DevOps Server 2022 Update 1 Patch 3 Tanggal Rilis: 12 Maret 2024

File	SHA-256 Hash
devops2022.1patch3.exe	E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Kami telah merilis Patch 3 untuk Azure DevOps Server 2022 Update 1 yang mencakup perbaikan untuk hal berikut.

• Mengatasi masalah di mana Server Proksi berhenti bekerja setelah menginstal Patch 2.
• Memperbaiki masalah penyajian pada halaman detail ekstensi yang memengaruhi bahasa yang bukan bahasa Inggris.

Azure DevOps Server 2022 Update 1 Patch 2 Tanggal Rilis: 13 Februari 2024

File	SHA-256 Hash
devops2022.1patch2.exe	59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

Kami telah merilis Patch 2 untuk Azure DevOps Server 2022 Update 1 yang mencakup perbaikan untuk yang berikut ini.

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

Azure DevOps Server 2022 Update 1 Patch 1 Tanggal Rilis: 12 Desember 2023

File	SHA-256 Hash
devops2022.1patch1.exe	9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

Kami telah merilis Patch 1 untuk Azure DevOps Server 2022 Update 1 yang mencakup perbaikan untuk yang berikut ini.

• Cegah pengaturan requested for saat mengantre eksekusi alur.

Azure DevOps Server 2022 Update 1 Tanggal Rilis: 28 November 2023

Catatan

Ada dua masalah yang diketahui dengan rilis ini:

1. Versi Agen tidak diperbarui setelah memutakhirkan ke Azure DevOps Server 2022.1 dan menggunakan Agen Pembaruan dalam konfigurasi Kumpulan Agen. Saat ini kami sedang mengerjakan patch untuk mengatasi masalah ini dan akan berbagi pembaruan di Komunitas Pengembang saat kami membuat kemajuan. Sementara itu, Anda dapat menemukan solusi untuk masalah ini di tiket Komunitas Pengembang ini.
2. Kompatibilitas Maven 3.9.x. Maven 3.9.x memperkenalkan perubahan mencolok dengan Azure Artifacts dengan memperbarui transportasi Maven Resolver default ke HTTP asli dari Wagon. Ini menyebabkan masalah autentikasi 401 bagi pelanggan yang menggunakan http, bukan https. Anda dapat menemukan detail selengkapnya tentang masalah ini di sini. Sebagai solusinya, Anda dapat terus menggunakan Maven 3.9.x dengan properti -Dmaven.resolver.transport=wagon. Perubahan ini memaksa Maven untuk menggunakan Wagon Resolver Transport. Lihat dokumentasi di sini untuk detail selengkapnya.

Azure DevOps Server 2022.1 adalah gulungan perbaikan bug. Ini termasuk semua fitur dalam Azure DevOps Server 2022.1 RC2 yang sebelumnya dirilis.

Catatan

Ada masalah yang diketahui dengan kompatibilitas Maven 3.9.x. Maven 3.9.x memperkenalkan perubahan mencolok dengan Azure Artifacts dengan memperbarui transportasi Maven Resolver default ke HTTP asli dari Wagon. Ini menyebabkan masalah autentikasi 401 bagi pelanggan yang menggunakan http, bukan https. Anda dapat menemukan detail selengkapnya tentang masalah ini di sini.

Sebagai solusinya, Anda dapat terus menggunakan Maven 3.9.x dengan properti -Dmaven.resolver.transport=wagon. Perubahan ini memaksa Maven untuk menggunakan Wagon Resolver Transport. Lihat dokumentasi di sini untuk detail selengkapnya.

Azure DevOps Server 2022 Update 1 RC2 Tanggal Rilis: 31 Oktober 2023

Azure DevOps Server 2022.1 RC2 adalah roll up perbaikan bug. Ini termasuk semua fitur dalam Azure DevOps Server 2022.1 RC1 yang sebelumnya dirilis.

Catatan

Ada masalah yang diketahui dengan kompatibilitas Maven 3.9.x. Maven 3.9.x memperkenalkan perubahan mencolok dengan Azure Artifacts dengan memperbarui transportasi Maven Resolver default ke HTTP asli dari Wagon. Ini menyebabkan masalah autentikasi 401 bagi pelanggan yang menggunakan http, bukan https. Anda dapat menemukan detail selengkapnya tentang masalah ini di sini.

Sebagai solusinya, Anda dapat terus menggunakan Maven 3.9.x dengan properti -Dmaven.resolver.transport=wagon. Perubahan ini memaksa Maven untuk menggunakan Wagon Resolver Transport. Lihat dokumentasi di sini untuk detail selengkapnya.

Berikut ini telah diperbaiki dengan rilis ini:

• Memperbaiki masalah pada umpan lokal di mana entri upstream tidak menyelesaikan perubahan nama tampilan.
• Terjadi kesalahan tak terduga saat beralih tab dari Kode ke tab lain di halaman Pencarian.
• Kesalahan saat membuat jenis item kerja baru dengan Ideograf Terpadu Bahasa Tionghoa, Jepang, dan Korea (CJK). Tanda tanya ditampilkan pada log RAW pada check-in terjaga ketika nama proyek tim atau file menyertakan CJK.
• Memperbaiki masalah selama penginstalan Pencarian di mana Java Virtual Machine (JVM) tidak dapat mengalokasikan cukup memori untuk proses Pencarian Elastis. Widget konfigurasi pencarian sekarang akan menggunakan Java Development Kit (JDK) yang dibundel dengan Elastic Search dan karenanya menghapus dependensi pada Java Runtime Environment (JRE) yang telah diinstal sebelumnya di server yang ditargetkan.

Azure DevOps Server 2022 Update 1 RC1 Tanggal Rilis: 19 September 2023

Azure DevOps Server 2022.1 RC1 mencakup banyak fitur baru. Beberapa sorotan meliputi:

• Semua REST API Publik mendukung cakupan PAT terperinci
• Kolom Terakhir Diakses pada halaman Paket Pengiriman
• Memvisualisasikan semua dependensi pada Paket Pengiriman
• @CurrentIteration makro dalam Paket Pengiriman
• Proyek saat ini ditetapkan sebagai cakupan default untuk membangun token akses di alur klasik
• Tampilkan Induk di Widget Hasil Kueri
• Salin Dasbor
• Dukungan untuk jenis diagram tambahan di halaman wiki
• Koneksi layanan Container Registry sekarang dapat menggunakan Azure Managed Identities

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

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

---

Umum

Semua REST API Publik mendukung cakupan PAT terperinci

Sebelumnya, sejumlah REST API Azure DevOps yang didokumentasikan secara publik tidak dikaitkan dengan cakupan (misalnya, baca item kerja) yang menyebabkan pelanggan menggunakan cakupan penuh untuk menggunakan API ini melalui mekanisme autentikasi non-interaktif seperti token akses pribadi (PAT). Menggunakan token akses pribadi cakupan penuh meningkatkan risiko ketika mereka dapat mendarat di tangan pengguna berbahaya. Ini adalah salah satu alasan utama bahwa banyak pelanggan kami tidak memanfaatkan sepenuhnya kebijakan sarana kontrol untuk membatasi penggunaan dan perilaku PAT.

Sekarang, semua REST API Azure DevOps publik sekarang dikaitkan dengan dan mendukung cakupan PAT terperinci. Jika saat ini Anda menggunakan PAT cakupan penuh untuk mengautentikasi ke salah satu REST API Azure DevOps publik, pertimbangkan untuk bermigrasi ke PAT dengan cakupan tertentu yang diterima oleh API untuk menghindari akses yang tidak perlu. Cakupan PAT terperinci yang didukung untuk REST API tertentu dapat ditemukan di bagian Keamanan halaman dokumentasi. Selain itu, ada tabel cakupan di sini.

Ekstensi harus menampilkan Cakupannya

Saat menginstal ekstensi ke koleksi Azure DevOps, Anda dapat meninjau izin yang dibutuhkan ekstensi sebagai bagian dari penginstalan. Namun, setelah diinstal, izin ekstensi tidak terlihat di pengaturan ekstensi. Ini telah menimbulkan tantangan bagi administrator yang perlu melakukan tinjauan berkala ekstensi yang diinstal. Sekarang, kami telah menambahkan izin ekstensi ke pengaturan ekstensi untuk membantu Anda meninjau dan mengambil keputusan berdasarkan informasi tentang apakah akan menyimpannya atau tidak.

Boards

Kolom Terakhir Diakses pada halaman Paket Pengiriman

Halaman direktori Paket Pengiriman menyediakan daftar paket yang ditentukan untuk proyek Anda. Anda dapat mengurutkan menurut: Nama, Dibuat Oleh, Deskripsi, Terakhir dikonfigurasi, atau Favorit. Dengan pembaruan ini, kami telah menambahkan kolom Terakhir diakses ke halaman direktori. Ini memberikan visibilitas tentang kapan Paket Pengiriman terakhir dibuka dan dilihat. Akibatnya, mudah untuk mengidentifikasi rencana yang tidak lagi digunakan dan dapat dihapus.

Memvisualisasikan semua dependensi pada Paket Pengiriman

Paket Pengiriman selalu menyediakan kemampuan untuk melihat dependensi di seluruh item kerja. Anda dapat memvisualisasikan baris dependensi, satu per satu. Dengan rilis ini, kami meningkatkan pengalaman dengan memungkinkan Anda melihat semua baris dependensi di semua item kerja di layar. Cukup klik tombol alih dependensi di kanan atas paket pengiriman Anda. Klik lagi untuk mematikan garis.

Batas revisi item kerja baru

Selama beberapa tahun terakhir, kami telah melihat koleksi proyek dengan alat otomatis menghasilkan puluhan ribu revisi item kerja. Ini menciptakan masalah dengan performa dan kegunaan pada formulir item kerja dan REST API pelaporan. Untuk mengurangi masalah ini, kami telah menerapkan batas revisi item kerja sebesar 10.000 ke Layanan Azure DevOps. Batas hanya memengaruhi pembaruan menggunakan REST API, bukan formulir item kerja.

Klik di sini untuk mempelajari lebih lanjut tentang batas revisi dan cara menanganinya di alat otomatis Anda.

Meningkatkan batas tim Paket Pengiriman dari 15 menjadi 20

Paket Pengiriman memungkinkan Anda melihat beberapa backlog dan beberapa tim di seluruh koleksi proyek Anda. Sebelumnya, Anda dapat melihat 15 backlog tim, termasuk campuran backlog dan tim dari berbagai proyek. Dengan rilis ini kami meningkatkan batas maksimum dari 15 menjadi 20.

Memperbaiki bug dalam Melaporkan Tautan Item Kerja Dapatkan API

Kami memperbaiki bug di Reporting Work Item Links Get API untuk mengembalikan nilai remoteUrl yang benar untuk System.LinkTypes.Remote.Related jenis tautan. Sebelum perbaikan ini, kami mengembalikan nama koleksi proyek yang salah dan id proyek yang hilang.

Membuat titik akhir REST kueri sementara

Kami telah melihat beberapa contoh penulis ekstensi yang mencoba menjalankan kueri yang belum disimpan dengan meneruskan pernyataan Work Item Query Language (WIQL) melalui querystring. Ini berfungsi dengan baik kecuali Anda memiliki pernyataan WIQL besar yang mencapai batas browser pada panjang querystring. Untuk mengatasinya, kami telah membuat titik akhir REST baru untuk memungkinkan penulis alat menghasilkan kueri sementara. Menggunakan id dari respons untuk meneruskan melalui querystring menghilangkan masalah ini.

Pelajari selengkapnya di halaman dokumentasi REST API kueri sementara.

API penghapusan batch

Saat ini, satu-satunya cara untuk menghapus item kerja dari keranjang sampah adalah dengan menggunakan REST API ini untuk menghapus satu per satu. Ini bisa menjadi proses yang lambat dan tunduk pada pembatasan tarif ketika mencoba untuk melakukan pembersihan massal apa pun. Sebagai tanggapan, kami telah menambahkan titik akhir REST API baru untuk menghapus dan/atau menghancurkan item kerja dalam batch.

@CurrentIteration makro dalam Paket Pengiriman

Dengan pembaruan ini, kami telah menambahkan dukungan untuk @CurrentIteration makro untuk gaya dalam Paket Pengiriman. Makro ini akan memungkinkan Anda mendapatkan iterasi saat ini dari konteks tim setiap baris dalam rencana Anda.

Logika mengubah ukuran kartu dalam Paket Pengiriman

Tidak semua orang menggunakan tanggal target dan/atau tanggal mulai saat melacak Fitur dan Epik. Beberapa memilih untuk menggunakan kombinasi tanggal dan jalur iterasi. Dalam rilis ini, kami meningkatkan logika untuk mengatur jalur iterasi dan kombinasi bidang tanggal dengan tepat tergantung pada bagaimana mereka digunakan.

Misalnya, jika tanggal target tidak digunakan dan Anda mengubah ukuran kartu, jalur iterasi baru diatur alih-alih memperbarui tanggal target.

Peningkatan pembaruan batch

Kami membuat beberapa perubahan pada versi 7.1 dari API pembaruan batch item kerja. Ini termasuk peningkatan performa kecil dan penanganan kegagalan parsial. Artinya, jika satu patch gagal tetapi yang lain tidak, yang lain akan berhasil diselesaikan.

Klik di sini untuk mempelajari selengkapnya tentang REST API pembaruan batch.

API penghapusan batch

Titik akhir REST API baru ini untuk menghapus dan/atau menghancurkan item kerja dalam batch sekarang tersedia untuk umum. Klik di sini untuk mempelajari selengkapnya.

Mencegah pengeditan bidang daftar pilih yang dapat dibagikan

Bidang kustom dibagikan di seluruh proses. Ini dapat membuat masalah untuk bidang daftar pilihan karena kami mengizinkan admin proses untuk menambahkan atau menghapus nilai dari bidang . Saat melakukannya, perubahan memengaruhi bidang tersebut pada setiap proses menggunakannya.

Untuk mengatasi masalah ini, kami telah menambahkan kemampuan admin koleksi untuk "mengunci" bidang agar tidak diedit. Saat bidang daftar pilih dikunci, admin proses lokal tidak dapat mengubah nilai daftar pilihan tersebut. Mereka hanya dapat menambahkan atau menghapus bidang dari proses.

Izin simpan komentar baru

Kemampuan untuk menyimpan hanya komentar item kerja telah menjadi permintaan teratas di komunitas pengembang. Kami sangat senang untuk memberi tahu Anda bahwa kami telah menerapkan fitur ini. Untuk memulai, mari kita tinjau skenario yang paling umum:

"Saya ingin mencegah beberapa pengguna mengedit bidang item kerja tetapi memungkinkan mereka untuk berkontribusi pada diskusi."

Untuk mencapai hal ini, Anda perlu membuka Jalur Area Konfigurasi > Proyek Pengaturan > Proyek. Lalu pilih jalur area pilihan dan klik Keamanan.

Perhatikan izin baru "Edit komentar item kerja di simpul ini". Secara default, izin diatur ke Tidak diatur. Artinya, item pekerjaan akan ber perilaku persis seperti sebelumnya. Untuk memperbolehkan grup atau pengguna menyimpan komentar, pilih grup/pengguna tersebut dan ubah izin ke Izinkan.

Ketika pengguna membuka formulir item kerja di jalur area ini, mereka akan dapat menambahkan komentar, tetapi tidak dapat memperbarui bidang lain.

Kami harap Anda menyukai fitur ini sebanyak yang kami lakukan. Seperti biasa, jika Anda memiliki umpan balik atau saran, beri tahu kami.

Laporan papan interaktif

Laporan interaktif, yang terletak di hub Boards, telah dapat diakses selama beberapa tahun dalam versi produk yang dihosting. Mereka menggantikan bagan Diagram Alur Kumulatif, Kecepatan, dan Sprint Burndown yang lebih lama. Dengan rilis ini kami membuatnya tersedia.

Untuk melihat bagan ini, klik lokasi tab Analitik di halaman Kanban Board, Backlog, dan Sprints.

Repos

Menghapus izin "Edit kebijakan" ke pembuat cabang

Sebelumnya, saat Anda membuat cabang baru, Anda kami diberi izin untuk mengedit kebijakan di cabang tersebut. Dengan pembaruan ini, kami mengubah perilaku default untuk tidak memberikan izin ini meskipun pengaturan "Manajemen izin" diaktifkan untuk repositori.

Anda akan memerlukan izin "Edit kebijakan" yang diberikan secara eksplisit (baik secara manual maupun melalui REST API) dengan pewarisan izin keamanan atau melalui keanggotaan grup.

Pipelines

Proyek saat ini ditetapkan sebagai cakupan default untuk membangun token akses dalam alur klasik

Azure Pipelines menggunakan token akses pekerjaan untuk mengakses sumber daya lain di Azure DevOps pada run-time. Token akses pekerjaan adalah token keamanan yang dihasilkan secara dinamis oleh Azure Pipelines untuk setiap pekerjaan pada durasi. Sebelumnya, saat membuat alur klasik baru, nilai default untuk token akses diatur ke Koleksi Proyek. Dengan pembaruan ini, kami mengatur cakupan otorisasi pekerjaan ke proyek saat ini sebagai default saat membuat alur klasik baru.

Anda dapat menemukan detail selengkapnya tentang token akses pekerjaan di repositori Akses, artefak, dan dokumentasi sumber daya lainnya.

Perubahan dalam cakupan default token akses dalam alur build klasik

Untuk meningkatkan keamanan alur build klasik, saat membuat yang baru, cakupan otorisasi pekerjaan build akan menjadi Project, secara default. Hingga saat ini, dulunya adalah Koleksi Proyek. Baca selengkapnya tentang Token akses pekerjaan. Perubahan ini tidak berdampak pada salah satu alur yang ada. Ini hanya berdampak pada alur build klasik baru yang Anda buat dari titik ini.

Dukungan Azure Pipelines untuk San Diego, Tokyo & rilis ServiceNow

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 San Diego, Tokyo & Utah dari ServiceNow. Untuk memastikan bahwa integrasi ini berfungsi, tingkatkan ke versi baru aplikasi (4.215.2) dari penyimpanan ServiceNow.

Untuk informasi selengkapnya, lihat dokumentasi Integrasikan dengan Manajemen Perubahan ServiceNow.

Menggunakan URL proksi untuk integrasi GitHub Enterprise

Azure Pipelines terintegrasi dengan GitHub Enterprise Server lokal untuk menjalankan integrasi berkelanjutan dan build PR. Dalam beberapa kasus, GitHub Enterprise Server berada di belakang firewall dan mengharuskan lalu lintas dirutekan melalui server proksi. Untuk mendukung skenario ini, koneksi layanan GitHub Enterprise Server di Azure DevOps memungkinkan Anda mengonfigurasi URL proksi. Sebelumnya, tidak semua lalu lintas dari Azure DevOps dirutekan melalui URL proksi ini. Dengan pembaruan ini, kami memastikan bahwa kami merutekan lalu lintas berikut dari Azure Pipelines untuk melalui URL proksi:

• Dapatkan cabang
• Dapatkan informasi permintaan pull
• Melaporkan status build

Koneksi layanan Container Registry sekarang dapat menggunakan Azure Managed Identities

Anda dapat menggunakan Identitas Terkelola yang ditetapkan Sistem saat membuat koneksi layanan Docker Registry untuk Azure Container Registry. Ini memungkinkan Anda mengakses Azure Container Registry menggunakan Identitas Terkelola yang terkait dengan agen Azure Pipelines yang dihost sendiri, menghilangkan kebutuhan untuk mengelola kredensial.

Catatan

Identitas Terkelola yang digunakan untuk mengakses Azure Container Registry akan memerlukan penetapan Azure Role Based Access Control (RBAC) yang sesuai, misalnya peran AcrPull atau AcrPush.

Token otomatis yang dibuat untuk Koneksi Layanan Kubernetes

Sejak Kubernetes 1.24, token tidak lagi dibuat secara otomatis saat membuat Koneksi Layanan Kubernetes baru. Kami telah menambahkan kembali fungsionalitas ini. Namun, disarankan untuk menggunakan koneksi Azure Service saat mengakses AKS, untuk mempelajari lebih lanjut lihat panduan Koneksi Layanan untuk pelanggan AKS menggunakan posting blog tugas Kubernetes.

Tugas Kubernetes sekarang mendukung kubelogin

Kami telah memperbarui tugas KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 , dan AzureFunctionOnKubernetes@1 untuk mendukung kubelogin. Hal ini memungkinkan Anda menargetkan Azure Kubernetes Service (AKS) yang dikonfigurasi dengan integrasi Azure Active Directory.

Kubelogin tidak diinstal sebelumnya pada Gambar yang dihosting. Untuk memastikan tugas yang disebutkan di atas menggunakan kubelogin, instal dengan menyisipkan tugas KubeloginInstaller@0 sebelum tugas yang bergantung padanya:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Mengalami penyempurnaan izin alur

Kami telah meningkatkan pengalaman sekeliling mengelola izin alur untuk membuat sistem izin mengingat apakah alur sebelumnya telah menggunakan sumber daya yang dilindungi, seperti koneksi layanan.

Di masa lalu, jika Anda mencentang "Berikan izin akses ke semua alur" saat Anda membuat sumber daya yang dilindungi, tetapi kemudian Anda membatasi akses ke sumber daya, alur Anda memerlukan otorisasi baru untuk menggunakan sumber daya. Perilaku ini tidak konsisten dengan akses pembukaan dan penutupan berikutnya ke sumber daya, di mana otorisasi baru tidak diperlukan. Ini sekarang diperbaiki.

Cakupan PAT baru untuk mengelola otorisasi dan persetujuan dan pemeriksaan alur

Untuk membatasi kerusakan yang dilakukan dengan membocorkan token PAT, kami telah menambahkan cakupan PAT baru, bernama Pipeline Resources. Anda dapat menggunakan cakupan PAT ini saat mengelola otorisasi alur menggunakan sumber daya yang dilindungi, seperti koneksi layanan, atau untuk mengelola persetujuan dan memeriksa sumber daya tersebut.

Panggilan REST API berikut mendukung cakupan PAT baru sebagai berikut:

• Memperbarui Persetujuan mendukung cakupan Pipeline Resources Use
• Kelola Pemeriksaan mendukung cakupan Pipeline Resources Use and Manage
• Perbarui Izin Alur Untuk Sumber Daya mendukung cakupan Pipeline Resources Use and Manage
• Sumber Daya Definisi Otorisasi mendukung cakupan Pipeline Resources Use and Manage
• Mengotorisasi Sumber Daya Proyek mendukung cakupan Pipeline Resources Use and Manage

Membatasi pembukaan sumber daya yang dilindungi untuk administrator sumber daya

Untuk meningkatkan keamanan sumber daya yang penting bagi kemampuan Anda untuk membangun dan menyebarkan aplikasi Anda dengan aman, Azure Pipelines sekarang memerlukan peran administrator jenis sumber daya saat membuka akses ke sumber daya ke semua alur.

Misalnya, peran Administrator Connections Layanan umum diperlukan untuk memungkinkan alur apa pun menggunakan koneksi layanan.. Pembatasan ini berlaku saat membuat sumber daya yang dilindungi atau saat mengedit konfigurasi Keamanannya.

Selain itu, saat membuat koneksi layanan, dan Anda tidak memiliki hak yang memadai, opsi Berikan izin akses ke semua alur dinonaktifkan.

Juga, ketika mencoba membuka akses ke sumber daya yang ada dan Anda tidak memiliki hak yang memadai, Anda akan mendapatkan Anda tidak berwenang untuk membuka akses untuk pesan sumber daya ini.

Peningkatan Keamanan REST API Alur

Sebagian besar REST API di Azure DevOps menggunakan token PAT terlingkup. Namun, beberapa di antaranya memerlukan token PAT yang sepenuhnya terlingkup. Dengan kata lain, Anda harus membuat token PAT dengan memilih 'Akses penuh' untuk menggunakan beberapa API ini. Token tersebut menimbulkan risiko keamanan karena dapat digunakan untuk memanggil REST API apa pun. Kami telah melakukan peningkatan di seluruh Azure DevOps untuk menghapus kebutuhan akan token yang sepenuhnya tercakup dengan menggabungkan setiap REST API ke dalam cakupan tertentu. Sebagai bagian dari upaya ini, REST API untuk memperbarui izin alur untuk sumber daya sekarang memerlukan cakupan tertentu. Cakupan tergantung pada jenis sumber daya yang diotorisasi untuk digunakan:

• Code (read, write, and manage) untuk sumber daya jenis repository
• Agent Pools (read, manage) atau Environment (read, manage) untuk sumber daya jenis queue dan agentpool
• Secure Files (read, create, and manage) untuk sumber daya jenis securefile
• Variable Groups (read, create and manage) untuk sumber daya jenis variablegroup
• Service Endpoints (read, query and manage) untuk sumber daya jenis endpoint
• Environment (read, manage) untuk sumber daya jenis environment

Untuk mengedit izin alur secara massal, Anda masih memerlukan token PAT yang sepenuhnya terlingkup. Untuk mempelajari selengkapnya tentang memperbarui izin Alur untuk sumber daya, lihat dokumentasi Izin Alur - Perbarui Izin Alur Untuk Sumber Daya .

Manajemen akses menenangkan untuk kumpulan agen

Kumpulan agen memungkinkan Anda menentukan dan mengelola komputer tempat alur Anda berjalan.

Sebelumnya, jika Anda menggunakan kumpulan agen kustom, mengelola alur mana yang dapat mengaksesnya secara kasar. Anda dapat mengizinkan semua alur untuk menggunakannya, atau Anda dapat mengharuskan setiap alur meminta izin. Sayangnya, setelah Anda memberikan izin akses alur ke kumpulan agen, Anda tidak dapat mencabutnya menggunakan UI alur.

Azure Pipelines sekarang menyediakan manajemen akses halus untuk kumpulan agen. Pengalaman ini mirip dengan yang untuk mengelola izin alur untuk Connections Layanan.

Mencegah pemberian akses semua alur ke sumber daya yang dilindungi

Saat Anda membuat sumber daya yang dilindungi seperti koneksi layanan atau lingkungan, Anda memiliki opsi untuk memilih kotak centang Berikan izin akses ke semua alur . Hingga saat ini, opsi ini dicentang secara default.

Meskipun ini memudahkan alur untuk menggunakan sumber daya baru yang dilindungi, sebaliknya adalah mendukung pemberian terlalu banyak alur secara tidak sengaja hak untuk mengakses sumber daya.

Untuk mempromosikan pilihan aman secara default, Azure DevOps sekarang membiarkan kotak centang tidak dicentang.

Kemampuan untuk menonaktifkan masking untuk rahasia pendek

Azure Pipelines menutupi rahasia dalam log. Rahasia dapat berupa variabel yang ditandai sebagai rahasia, variabel dari grup variabel yang ditautkan ke Azure Key Vault atau elemen Koneksi Layanan yang ditandai sebagai rahasia oleh penyedia Koneksi Layanan.

Semua kemunculan nilai rahasia ditutupi. Menutupi rahasia pendek misalnya '1', '2', 'Dev' memudahkan untuk menebak nilainya misalnya dalam tanggal: 'Jan 3, 202***'
Sekarang jelas '3' adalah rahasia. Dalam kasus seperti itu, Anda mungkin lebih suka tidak menutupi rahasia sama sekali. Jika tidak dimungkinkan untuk tidak menandai nilai sebagai rahasia (misalnya nilai diambil dari Key Vault), Anda dapat mengatur AZP_IGNORE_SECRETS_SHORTER_THAN kenop ke nilai hingga 4.

Tugas pengunduhan runner simpul

Saat mengadopsi rilis agen yang mengecualikan runner tugas Node 6 , Anda mungkin memiliki kebutuhan sesekali untuk menjalankan tugas yang belum diperbarui untuk menggunakan runner Node yang lebih baru. Untuk skenario ini, kami menyediakan metode untuk tetap menggunakan tugas tergantung pada runner Node End-of-Life, lihat Posting blog panduan runner node.

Tugas di bawah ini adalah metode untuk menginstal runner Node 6 just-in-time, sehingga tugas lama masih dapat dijalankan:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

Validasi runner TFX Node yang diperbarui

Penulis tugas menggunakan alat pengemasan ekstensi (TFX) untuk menerbitkan ekstensi. TFX telah diperbarui untuk melakukan validasi pada versi runner Node, lihat Posting blog panduan runner node.

Ekstensi yang berisi tugas menggunakan runner Node 6 akan melihat peringatan ini:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Instruksi untuk pra-penginstalan manual Node 6 pada agen Alur

Jika Anda menggunakan pipeline- umpan agen, Anda tidak memiliki Node 6 yang disertakan dalam agen. Dalam beberapa kasus, ketika tugas Marketplace masih bergantung pada Node 6 dan agen tidak dapat menggunakan tugas NodeTaskRunnerInstaller (misalnya karena pembatasan konektivitas), Anda harus melakukan pra-instal Node 6 terlebih dahulu secara terpisah. Untuk melakukannya, lihat instruksi tentang cara menginstal runner Node 6 secara manual.

Log perubahan tugas alur

Kami kini menerbitkan perubahan pada tugas Alur ke changelog ini. Ini berisi daftar lengkap perubahan yang dibuat pada tugas Alur bawaan. Kami telah secara retroaktif menerbitkan perubahan sebelumnya, sehingga changelog memberikan catatan historis pembaruan tugas.

Tugas rilis menggunakan Microsoft Graph API

Kami telah memperbarui tugas rilis kami untuk menggunakan Microsoft Graph API. Ini menghapus penggunaan AAD Graph API dari tugas kami.

Windows PowerShell peningkatan performa tugas

Anda dapat menggunakan tugas untuk menentukan otomatisasi dalam alur. Salah satu tugas ini adalah PowerShell@2 tugas utilitas yang memungkinkan Anda menjalankan skrip PowerShell di alur Anda. Untuk menggunakan skrip PowerShell untuk menargetkan lingkungan Azure, Anda bisa menggunakan tugas tersebut AzurePowerShell@5 . Beberapa perintah PowerShell yang dapat mencetak pembaruan kemajuan, misalnya Invoke-WebRequest, sekarang jalankan lebih cepat. Peningkatannya lebih signifikan jika Anda memiliki banyak perintah ini dalam skrip Anda, atau ketika mereka berjalan lama. Dengan pembaruan ini, progressPreference properti tugas dan AzurePowerShell@5 sekarang diatur ke SilentlyContinue secara PowerShell@2 default.

Agen Alur v3 di .NET 6

Agen Alur telah ditingkatkan untuk menggunakan .NET 3.1 Core ke .NET 6 sebagai runtimenya. Ini memperkenalkan dukungan asli untuk Apple Silicon serta Windows Arm64.

Menggunakan .NET 6 berdampak pada persyaratan sistem untuk agen. Secara khusus, kami menghilangkan dukungan untuk Sistem Operasi berikut: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Lihat dokumentasi perangkat lunak Agen versi 3.

Skrip ini dapat digunakan untuk mengidentifikasi alur yang menggunakan agen dengan sistem operasi yang tidak didukung.

Penting

Perlu diketahui bahwa agen yang berjalan pada salah satu sistem operasi di atas tidak akan lagi memperbarui atau gagal setelah kami meluncurkan agen berbasis .NET 6.

Tentukan versi agen di ekstensi VM Agen

Azure VM dapat disertakan dalam Grup Penyebaran menggunakan Ekstensi VM. Ekstensi VM telah diperbarui untuk secara opsional menentukan versi agen yang diinginkan untuk diinstal:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

Pengalih baru untuk mengontrol pembuatan alur klasik

Azure DevOps sekarang memungkinkan Anda memastikan koleksi proyek Anda hanya menggunakan alur YAML, dengan menonaktifkan pembuatan alur build klasik, alur rilis klasik, grup tugas, dan grup penyebaran. Alur klasik yang ada akan terus berjalan, dan Anda akan dapat mengeditnya, tetapi Anda tidak akan dapat membuat yang baru.

Azure DevOps sekarang memungkinkan Anda memastikan organisasi Anda hanya menggunakan alur YAML, dengan menonaktifkan pembuatan alur build klasik, alur rilis klasik, grup tugas, dan grup penyebaran. Alur klasik yang ada akan terus berjalan, dan Anda akan dapat mengeditnya, tetapi Anda tidak akan dapat membuat yang baru.

Anda dapat menonaktifkan pembuatan alur klasik di tingkat pengumpulan proyek atau tingkat proyek, dengan mengaktifkan pengalih yang sesuai. Tombol dapat ditemukan di Pengaturan Proyek / Proyek -> Alur -> Pengaturan. Ada dua pengalih: satu untuk alur build klasik dan satu untuk alur rilis klasik, grup penyebaran, dan grup tugas.

Status tombol mati secara default, dan Anda akan memerlukan hak admin untuk mengubah status. Jika pengalih aktif di tingkat organisasi, penonaktifan diberlakukan untuk semua proyek. Jika tidak, setiap proyek bebas untuk memilih apakah akan memberlakukan atau tidak penonaktifan.

Saat menonaktifkan pembuatan alur klasik diberlakukan, REST API yang terkait dengan pembuatan alur klasik, grup tugas, dan grup penyebaran akan gagal. REST API yang membuat alur YAML akan berfungsi.

Updates ke peristiwa kait layanan "Jalankan perubahan status tahap"

Kait layanan memungkinkan Anda menjalankan tugas di layanan lain saat peristiwa terjadi di proyek Anda di Azure DevOps, status Eksekusi tahap yang diubah adalah salah satu peristiwa ini. Peristiwa perubahan status tahap eksekusi harus berisi informasi tentang eksekusi termasuk nama alur. Sebelumnya, ini hanya menyertakan informasi tentang id dan nama eksekusi. Dengan pembaruan ini, kami membuat perubahan pada peristiwa untuk menyertakan informasi yang hilang.

Menonaktifkan memperlihatkan pesan penerapan terakhir untuk eksekusi alur

Sebelumnya, UI Alur yang digunakan untuk menampilkan pesan penerapan terakhir saat menampilkan eksekusi alur.

Pesan ini dapat membingungkan, misalnya, ketika kode alur YAML Anda berada di repositori yang berbeda dari yang menyimpan kode yang sedang dibangunnya. Kami mendengar umpan balik Anda dari Komunitas Pengembang yang meminta cara untuk mengaktifkan/menonaktifkan penambahan pesan penerapan terbaru ke judul setiap eksekusi alur.

Dengan pembaruan ini, kami telah menambahkan properti YAML baru, bernama appendCommitMessageToRunName, yang memungkinkan Anda melakukannya dengan tepat. Secara default, properti diatur ke true. Ketika Anda mengaturnya ke false, eksekusi alur hanya akan menampilkan BuildNumber.

Peningkatan batas Azure Pipeline untuk menyelaraskan dengan ukuran templat Azure Resource Manager (ARM) maksimum 4 MB.

Anda dapat menggunakan tugas Penyebaran Templat Azure Resource Manager untuk membuat infrastruktur Azure. Menanggapi umpan balik Anda, kami telah meningkatkan batas integrasi Azure Pipelines sebesar 2 MB menjadi 4 MB. Ini akan selaras dengan ukuran maksimum Templat ARM sebesar 4 MB mengatasi batasan ukuran selama integrasi templat besar.

Ikon gambaran umum status eksekusi alur

Dengan rilis ini, kami mempermudah untuk mengetahui status keseluruhan eksekusi alur.

Untuk alur YAML yang memiliki banyak tahapan, dulu sulit untuk mengetahui status eksekusi alur, yaitu masih berjalan atau selesai. Dan jika selesai, apa status keseluruhan: berhasil, gagal, atau dibatalkan. Kami memperbaiki masalah ini dengan menambahkan ikon gambaran umum status eksekusi.

Panel samping tahapan alur

Alur YAML dapat memiliki puluhan tahap, dan tidak semuanya akan pas di layar Anda. Meskipun ikon gambaran umum eksekusi alur memberi tahu Anda status keseluruhan eksekusi Anda, masih sulit untuk mengetahui tahap mana yang gagal, atau tahap mana yang masih berjalan, misalnya.

Dalam rilis ini, kami telah menambahkan panel samping tahapan alur yang memungkinkan Anda dengan cepat melihat status semua tahapan Anda. Anda kemudian dapat mengeklik panggung dan langsung masuk ke lognya.

Mencari tahapan di panel samping

Kami telah mempermudah untuk menemukan tahapan yang Anda cari di panel samping tahapan. Anda sekarang dapat dengan cepat memfilter tahapan berdasarkan statusnya, misalnya menjalankan tahapan atau tahapan yang memerlukan intervensi manual. Anda juga dapat mencari tahapan berdasarkan namanya.

Tindakan cepat tahapan

Layar Eksekusi alur memberi Anda akses cepat ke semua tahap eksekusi. Dalam rilis ini, kami telah menambahkan panel tahapan tempat Anda dapat melakukan tindakan untuk setiap tahap. Misalnya, Anda dapat dengan mudah menjalankan ulang pekerjaan yang gagal atau menjalankan ulang seluruh tahap. Panel tersedia ketika tidak semua tahap cocok di antarmuka pengguna, seperti yang Anda lihat di cuplikan layar berikut.

Saat Anda mengklik tanda '+' di kolom tahapan, panel tahapan muncul, lalu Anda dapat melakukan tindakan tahapan.

Memeriksa peningkatan pengalaman pengguna

Kami mempermudah proses membaca log pemeriksaan. Log pemeriksaan memberikan informasi penting untuk keberhasilan penyebaran Anda. Mereka dapat memberi tahu Anda jika Anda lupa menutup tiket item kerja, atau bahwa Anda perlu memperbarui tiket di ServiceNow. Sebelumnya, mengetahui bahwa pemeriksaan yang diberikan informasi penting tersebut sulit.

Sekarang, halaman detail eksekusi alur menunjukkan log pemeriksaan terbaru. Ini hanya untuk pemeriksaan yang mengikuti penggunaan yang kami rekomendasikan.

Untuk mencegah Persetujuan yang disetujui secara keliru, Azure DevOps memperlihatkan Instruksi kepada pemberi persetujuan di panel samping Persetujuan dan pemeriksaan di halaman detail eksekusi alur.

Menonaktifkan pemeriksaan

Kami membuat pemeriksaan debugging kurang melelahkan. Terkadang, pemeriksaan Panggil Azure Function atau Panggil REST API tidak berfungsi dengan benar, dan Anda perlu memperbaikinya. Sebelumnya, Anda harus menghapus pemeriksaan tersebut, untuk mencegahnya memblokir penyebaran secara keliru. Setelah memperbaiki pemeriksaan, Anda harus menambahkannya kembali dan mengonfigurasinya dengan benar, memastikan semua header yang diperlukan diatur atau parameter kueri sudah benar. Ini melelahkan.

Sekarang, Anda hanya dapat menonaktifkan pemeriksaan. Pemeriksaan yang dinonaktifkan tidak akan berjalan dalam evaluasi rangkaian pemeriksaan berikutnya.

Setelah Anda memperbaiki pemeriksaan yang salah, Anda hanya dapat mengaktifkannya.

Sumber daya dan parameter templat yang digunakan di Pipelines Runs Rest API

Pipelines Runs REST API yang diperluas sekarang mengembalikan lebih banyak jenis artefak yang digunakan oleh eksekusi alur dan parameter yang digunakan untuk memicu eksekusi tersebut. Kami meningkatkan API untuk mengembalikan container sumber daya dan pipeline dan parameter templat yang digunakan dalam eksekusi alur. Anda sekarang dapat, misalnya, menulis pemeriksaan kepatuhan yang mengevaluasi repositori, kontainer, dan eksekusi alur lainnya yang digunakan oleh alur.

Berikut adalah contoh isi respons baru.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Dukungan templat Ketersediaan Umum di editor YAML

Templat adalah fitur yang umum digunakan dalam alur YAML. Ini adalah cara mudah untuk berbagi cuplikan alur. Ini juga merupakan mekanisme yang kuat dalam memverifikasi atau menegakkan keamanan dan tata kelola melalui alur Anda.

Azure Pipelines mendukung editor YAML, yang dapat membantu saat mengedit alur Anda. Namun editor tidak mendukung templat hingga saat ini. Penulis alur YAML tidak bisa mendapatkan bantuan melalui intellisense saat menggunakan templat. Penulis templat tidak dapat menggunakan editor YAML. Dalam rilis ini, kami menambahkan dukungan untuk templat di editor YAML.

Saat mengedit file YAML Azure Pipelines utama, Anda dapat menyertakan atau memperluas templat. Saat Anda mengetikkan nama templat, Anda akan diminta untuk memvalidasi templat Anda. Setelah divalidasi, editor YAML memahami skema templat termasuk parameter input.

Pasca validasi, Anda dapat memilih untuk menavigasi ke dalam templat. Anda akan dapat membuat perubahan pada templat menggunakan semua fitur editor YAML.

Ada batasan yang diketahui:

• Jika templat memiliki parameter yang diperlukan yang tidak disediakan sebagai input dalam file YAML utama, validasi gagal dan meminta Anda untuk memberikan input tersebut. Dalam pengalaman yang ideal, validasi tidak boleh diblokir, dan Anda harus dapat mengisi parameter input menggunakan intellisense.
• Anda tidak dapat membuat templat baru dari editor. Anda hanya dapat menggunakan atau mengedit templat yang sudah ada.

Variabel sistem baru yang telah ditentukan sebelumnya

Kami memperkenalkan variabel sistem baru yang telah ditentukan sebelumnya, bernama Build.DefinitionFolderPath, yang nilainya adalah jalur folder dari definisi alur build. Variabel tersedia dalam alur BUILD YAML dan klasik.

Misalnya, jika alur Anda ditempatkan di bawah FabrikamFiber\Chat folder di Azure Pipelines, maka nilainya Build.DefinitionFolderPath adalah FabrikamFiber\Chat.

Menambahkan dukungan untuk fungsi pemisahan string dalam ekspresi templat YAML

Alur YAML memberi Anda cara mudah untuk mengurangi duplikasi kode, seperti mengulang nilai each daftar atau properti objek.

Terkadang, kumpulan item yang akan diulang direpresentasikan sebagai string. Misalnya, ketika daftar lingkungan yang akan disebarkan ditentukan oleh string integration1, integration2.

Saat kami mendengarkan umpan balik Anda dari Komunitas Pengembang, kami mendengar Anda menginginkan fungsi string split dalam ekspresi templat YAML.

Sekarang, Anda dapat split string dan melakukan iterasi di atas each substringnya.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Ekspresi Templat dalam Definisi Sumber Daya Repositori

Kami telah menambahkan dukungan untuk ekspresi templat saat menentukan ref properti repository sumber daya dalam alur YAML. Ini adalah fitur yang sangat diminta oleh Komunitas Pengembang kami.

Ada kasus penggunaan ketika Anda ingin alur Anda memeriksa cabang yang berbeda dari sumber daya repositori yang sama.

Misalnya, Anda memiliki alur yang membangun repositorinya sendiri, dan untuk ini, perlu memeriksa pustaka dari repositori sumber daya. Selain itu, katakanlah Anda ingin alur Anda memeriksa cabang pustaka yang sama seperti yang digunakan. Misalnya, jika alur Anda berjalan di main cabang, alur harus memeriksa main cabang repositori pustaka. Jika alur berjalan di dev cabang, alur harus memeriksa dev cabang pustaka.

Hingga hari ini, Anda harus secara eksplisit menentukan cabang untuk diperiksa, dan mengubah kode alur setiap kali cabang berubah.

Sekarang, Anda dapat menggunakan ekspresi templat untuk memilih cabang sumber daya repositori. Lihat contoh kode YAML berikut yang akan digunakan untuk cabang non-utama alur Anda:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Saat Anda menjalankan alur, Anda dapat menentukan cabang untuk library memeriksa repositori.

Tentukan versi templat yang akan diperluas pada waktu antrean build

Templat mewakili cara yang bagus untuk mengurangi duplikasi kode danmeningkatkan keamanan alur Anda.

Salah satu kasus penggunaan populer adalah menampung templat di repositori mereka sendiri. Ini mengurangi konupling antara templat dan alur yang memperluasnya dan membuatnya lebih mudah untuk mengembangkan templat dan alur secara independen.

Pertimbangkan contoh berikut, di mana templat digunakan untuk memantau eksekusi daftar langkah. Kode templat terletak di repositori Templates .

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Katakanlah Anda memiliki alur YAML yang memperluas templat ini, yang terletak di repositori FabrikamFiber. Hingga hari ini, tidak mungkin untuk menentukan ref properti templates sumber daya repositori secara dinamis saat menggunakan repositori sebagai sumber templat. Ini berarti Anda harus mengubah kode alur jika Anda ingin alur Anda untuk: memperluas templat dari cabang yang berbeda memperluas templat dari nama cabang yang sama dengan alur Anda, terlepas dari cabang mana Anda menjalankan alur Anda

Dengan pengenalan ekspresi templat dalam definisi sumber daya repositori, Anda dapat menulis alur Anda sebagai berikut:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Dengan demikian, alur Anda akan memperluas templat di cabang yang sama dengan cabang tempat alur berjalan, sehingga Anda dapat memastikan cabang alur dan templat Anda selalu cocok. Artinya, jika Anda menjalankan alur Anda di cabang dev, itu akan memperluas templat yang ditentukan oleh template.yml file di dev cabang templates repositori.

Atau Anda dapat memilih, pada build queue-time, cabang repositori templat mana yang akan digunakan, dengan menulis kode YAML berikut.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

Sekarang, Anda dapat memiliki alur Anda di cabang main memperluas templat dari cabang dev dalam satu eksekusi, dan memperluas templat dari cabang main dalam eksekusi lain, tanpa mengubah kode alur Anda.

Saat menentukan ekspresi templat untuk ref properti sumber daya repositori, Anda dapat menggunakan parameters dan variabel yang telah ditentukan sebelumnya sistem, tetapi Anda tidak dapat menggunakan variabel yang ditentukan YAML atau Alur UI.

Ekspresi Templat dalam Definisi Sumber Daya Kontainer

Kami telah menambahkan dukungan untuk ekspresi templat saat menentukan endpointproperti container , , volumesports, dan options sumber daya dalam alur YAML. Ini adalah fitur yang sangat diminta oleh Komunitas Pengembang kami.

Sekarang, Anda dapat menulis alur YAML seperti berikut ini.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Anda dapat menggunakan parameters. dan variables. dalam ekspresi templat Anda. Untuk variabel, Anda hanya dapat menggunakan yang ditentukan dalam file YAML, tetapi tidak yang ditentukan dalam UI Alur. Jika Anda menentukan ulang variabel, misalnya, menggunakan perintah log agen, itu tidak akan berpengaruh apa pun.

Peningkatan build terjadwal

Kami memperbaiki masalah yang menyebabkan informasi jadwal alur rusak, dan alur tidak dimuat. Ini disebabkan misalnya, ketika nama cabang melebihi jumlah karakter tertentu.

Pesan kesalahan yang disempurnakan saat gagal memuat alur

Azure Pipelines menyediakan beberapa jenis pemicu untuk mengonfigurasi cara alur Anda dimulai. Salah satu cara untuk menjalankan alur adalah dengan menggunakan pemicu terjadwal. Terkadang, informasi Eksekusi Terjadwal dari alur rusak dan dapat menyebabkan beban gagal. Sebelumnya, kami menampilkan pesan kesalahan yang menyesatkan, yang mengklaim bahwa alur tidak ditemukan. Dengan pembaruan ini, kami menyelesaikan masalah ini dan mengembalikan pesan kesalahan informatif. Ke depannya Anda akan menerima pesan yang mirip dengan: Data jadwal build rusak jika alur gagal dimuat.

Jangan sinkronkan tag saat mengambil repositori Git

Tugas checkout menggunakan --tags opsi dalam mengambil konten repositori Git. Ini menyebabkan server mengambil semua tag serta semua objek yang ditujukkan oleh tag tersebut. Ini meningkatkan waktu untuk menjalankan tugas dalam alur - terutama jika Anda memiliki repositori besar dengan sejumlah tag. Selain itu, tugas checkout menyinkronkan tag bahkan ketika Anda mengaktifkan opsi pengambilan dangkal, sehingga mungkin mengalahkan tujuannya. Untuk mengurangi jumlah data yang diambil atau ditarik dari repositori Git, kami sekarang telah menambahkan opsi baru ke tugas untuk mengontrol perilaku sinkronisasi tag. Opsi ini tersedia baik dalam alur klasik maupun YAML.

YAML

Perilaku ini dapat dikontrol dari file YAML atau dari UI.

Untuk menolak menyinkronkan tag melalui file YAML, tambahkan fetchTags: false ke langkah checkout. fetchTags Ketika opsi tidak ditentukan, opsinya sama seperti jika fetchTags: true digunakan.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Jika Anda ingin mengubah perilaku alur YAML yang ada, mungkin lebih nyaman untuk mengatur opsi ini di UI alih-alih memperbarui file YAML. Untuk menavigasi ke UI, buka editor YAML untuk alur, pilih Pemicu, lalu Proses, lalu langkah Checkout.

Jika Anda menentukan pengaturan ini baik dalam file YAML maupun di UI, maka nilai yang ditentukan dalam file YAML lebih diutamakan.

Klasik

Untuk menolak menyinkronkan tag, hapus centang pada kotak centang Sinkronkan tag di langkah dapatkan sumber.

Untuk semua alur baru yang Anda buat (YAML atau Klasik), tag masih disinkronkan secara default. Opsi ini tidak mengubah perilaku alur yang ada. Tag masih akan disinkronkan dalam alur tersebut kecuali Anda secara eksplisit mengubah opsi seperti yang dijelaskan di atas.

Artefak

Izin umpan default yang diperbarui

Akun Project Collection Build Service sekarang akan memiliki peran Kolaborator secara default saat umpan Azure Artifacts dengan cakupan koleksi proyek baru dibuat, bukan peran Kontributor saat ini.

Antarmuka pengguna baru untuk pencarian paket upstream

Sebelumnya, Anda dapat melihat paket upstream jika Anda memiliki salinan umpan. Titik nyerinya adalah Anda tidak dapat mencari paket yang tersedia di hulu dan yang belum disimpan dalam umpan. Sekarang, Anda dapat mencari paket upstream yang tersedia dengan antarmuka pengguna umpan baru.

Azure Artifacts sekarang menyediakan antarmuka pengguna yang memungkinkan Anda mencari paket di sumber upstream Anda dan menyimpan versi paket ke dalam umpan Anda. Ini selaras dengan tujuan Microsoft untuk meningkatkan produk dan layanan kami.

Pelaporan

Tampilkan Induk di Widget Hasil Kueri

Widget Hasil Kueri sekarang mendukung nama induk dan tautan langsung ke induk tersebut.

Dasbor Salin

Dengan rilis ini, kami menyertakan Dasbor Salin.

Dasbor Tanggal Terakhir Diakses dan Diubah Oleh

Salah satu tantangan memungkinkan tim membuat beberapa dasbor adalah pengelolaan dan pembersihan yang sudah kedaluarsa dan tidak digunakan. Mengetahui kapan dasbor terakhir dikunjungi atau dimodifikasi adalah bagian penting untuk memahami dasbor mana yang dapat dihapus. Dalam rilis ini, kami telah menyertakan dua kolom baru ke halaman direktori Dasbor. Tanggal Diakses Terakhir akan melacak kapan dasbor terakhir dikunjungi. Diubah Oleh trek saat dasbor terakhir diedit dan oleh siapa.

Informasi Dimodifikasi Oleh juga akan ditampilkan di halaman dasbor itu sendiri.

Kami berharap bidang baru ini membantu administrator proyek memahami tingkat aktivitas dasbor untuk membuat keputusan terdidik jika harus dihapus atau tidak.

Tampilan Analitik sekarang tersedia

Fitur Tampilan Analitik telah dalam status pratinjau untuk jangka waktu yang lama dalam versi produk yang dihosting. Dengan rilis ini kami dengan senang hati mengumumkan bahwa fitur ini sekarang tersedia untuk semua koleksi proyek.

Di navigasi, tampilan Analitik dipindahkan dari tab Gambaran Umum ke tab Papan .

Tampilan Analitik menyediakan cara yang disederhanakan untuk menentukan kriteria filter untuk laporan Power BI berdasarkan data Analytics. Jika Anda tidak terbiasa dengan Tampilan Analitik, berikut adalah beberapa dokumentasi untuk membuat Anda terjebak:

• Tentang tampilan Analitik
• Membuat tampilan Analitik di Azure DevOps
• Mengelola tampilan Analitik
• Membuat laporan Power BI dengan tampilan Analitik default
• Menghubungkan ke Analytics dengan Konektor Data Power BI

Widget Permintaan Pull untuk beberapa repositori sekarang tersedia

Kami sangat senang mengumumkan bahwa widget Permintaan Pull untuk beberapa repositori tersedia di Azure DevOps Server 2022.1. Dengan widget baru ini, Anda dapat dengan mudah melihat permintaan pull dari hingga 10 repositori yang berbeda dalam satu daftar yang disederhanakan, sehingga lebih mudah daripada sebelumnya untuk tetap berada di atas permintaan pull Anda.

Tiket saran komunitas

Memperkenalkan diselesaikan sebagai selesai dalam bagan burndown dan burnup

Kami memahami pentingnya mencerminkan kemajuan tim secara akurat, termasuk item yang diselesaikan sebagaimana diselesaikan dalam bagan. Dengan opsi pengalih sederhana, Anda sekarang dapat memilih untuk menampilkan item yang diselesaikan sebagai selesai, memberikan refleksi sebenarnya dari status burndown tim. Peningkatan ini memungkinkan pelacakan dan perencanaan yang lebih akurat, memberdayakan tim untuk membuat keputusan berdasarkan kemajuan aktual. Pengalaman transparansi yang ditingkatkan dan wawasan yang lebih baik dengan bagan burndown dan burnup yang diperbarui dalam Pelaporan.

Wiki

Dukungan untuk jenis diagram tambahan di halaman wiki

Kami telah meningkatkan versi bagan putri duyung yang digunakan di halaman wiki menjadi 8.13.9. Dengan peningkatan ini, Anda sekarang dapat menyertakan diagram dan visualisasi berikut di halaman wiki Azure DevOps Anda:

• Diagram Alur
• Diagram urutan
• Bagan Gantt
• Diagram pai
• Diagram persyaratan
• Diagram status
• Perjalanan Pengguna

Diagram yang berada dalam mode eksperimental seperti Hubungan Entitas dan Grafik Git tidak disertakan. Untuk informasi selengkapnya tentang fitur baru, silakan lihat catatan rilis putri duyung.

---

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