Bagikan melalui

Ketersediaan umum federasi identitas Beban Kerja untuk koneksi layanan Azure Resource Manager

  • Artikel

Kami sangat senang mengumumkan bahwa federasi identitas Beban Kerja sekarang tersedia secara umum di Azure Pipelines! Anda dapat menikmati pengalaman yang disederhanakan tanpa perlu mengelola rahasia dan sertifikat di koneksi layanan Azure.

Dengan pembaruan ini, kami juga mempratinjau fitur baru sebagai bagian dari integrasi GitHub kami yang ditingkatkan dengan Azure Boards. Anda sekarang dapat menautkan langsung ke permintaan atau penerapan pull GitHub. Tidak ada lagi peralihan antara jendela atau salin/tempel. Cukup pilih repositori yang Anda inginkan, temukan permintaan pull atau penerapan yang Anda butuhkan, dan tautkan!

Lihat catatan rilis untuk mempelajari selengkapnya tentang fitur-fitur ini.

Umum

GitHub Advanced Security untuk Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

Umum

Pemberitahuan akhir penghentian kredensial alternatif

Kredensial alternatif secara resmi tidak digunakan lagi pada Maret 2020, tetapi beberapa pengguna yang ada kakek dengan penggunaan kredensial alternatif yang ada yang sedang berlangsung. Pada Januari 2024 kami telah sepenuhnya menghentikan semua kredensial alternatif. Untuk menghindari potensi gangguan, beralihlah ke salah satu mekanisme autentikasi yang tersedia yang kami sediakan, seperti token akses pribadi atau identitas terkelola.

Rotasi rahasia layanan mandiri Azure Devops OAuth

Setiap lima tahun, penting untuk memperbarui Rahasia Klien untuk aplikasi Azure DevOps OAuth Anda, untuk memastikan pembuatan token akses dan refresh berkelanjutan yang diperlukan untuk menggunakan API Azure DevOps. Saat Rahasia Klien Anda mendekati kedaluwarsa, Anda sekarang dapat secara independen menghasilkan yang baru, memberi tim Anda kebebasan untuk mengelolanya tanpa mengandalkan dukungan pelanggan. Fleksibilitas dalam penjadwalan rotasi rahasia ini meminimalkan potensi waktu pemadaman bagi pelanggan Anda yang menunggu pengganti karena rahasia yang kedaluwarsa.

Cuplikan layar Pilih geografi.

Cari fungsionalitas baru ini di setiap halaman aplikasi Azure DevOps Anda yang dapat diakses melalui profil Anda di sini. Pelajari selengkapnya tentang langkah baru ini di panduan Azure DevOps OAuth kami.

GitHub Advanced Security untuk Azure DevOps

Cuplikan kode sekarang tersedia dalam tampilan detail pemberitahuan

Halaman detail pemberitahuan untuk pemindaian kode dan pemberitahuan pemindaian rahasia sekarang menunjukkan cuplikan kode yang menandai satu atau beberapa baris kode tempat pemberitahuan terjadi. Untuk masuk ke file asli di repositori Azure DevOps Anda, klik nama file di atas cuplikan kode.

Cuplikan layar jalur middleware peka huruf besar/kecil.

Rahasia terpotong ditampilkan dalam gambaran umum pemberitahuan

Enam karakter terakhir yang terpotong dari rahasia yang terdeteksi sekarang ditampilkan di layar gambaran umum pemberitahuan rahasia. Fitur ini sangat membantu jika Anda memiliki beberapa paparan rahasia dari jenis rahasia yang sama, memungkinkan Anda untuk dengan cepat mengidentifikasi tempat rahasia tertentu berada.

Cuplikan layar daftar pemberitahuan rahasia.

Tingkat keparahan pemberitahuan lainnya ditambahkan untuk pemberitahuan pemindaian kode

Tingkat keparahan pemberitahuan baru sekarang ada untuk hasil pemberitahuan dari kueri CodeQL quality sebagai Error, Warning, dan Note tingkat keparahan. Setiap tingkat keparahan pemberitahuan kualitas memiliki lencana dan warnanya sendiri untuk menunjukkan tingkat keparahan penskalaan. Anda juga dapat memfilter untuk setiap tingkat keparahan ini, mirip low dengan skala tingkat keparahan critical untuk pemberitahuan keamanan.

Cuplikan layar daftar pemberitahuan pemindaian kode dan filter tingkat keparahan.

Langganan Azure tertaut diperlukan untuk pengaktifan GitHub Advanced Security untuk Azure DevOps

Jika sebelumnya Anda mengaktifkan Advanced Security untuk repositori di organisasi Azure DevOps tanpa langganan Azure tertaut, Anda mungkin melihat Advanced Security secara otomatis menonaktifkan dirinya sendiri di repositori tersebut. Untuk mengaktifkan kembali Keamanan Tingkat Lanjut, tambahkan langganan Azure terkait ke organisasi. Untuk informasi selengkapnya tentang cara menambahkan atau mengubah langganan Anda, lihat Mengubah langganan Azure.

Pembaruan API Keamanan Tingkat Lanjut

Berbagai pembaruan untuk API Keamanan Tingkat Lanjut baru-baru ini dikirim:

  • GET Alerts API sekarang mendukung parameter baru, ModifiedSince, untuk mengembalikan daftar pemberitahuan inkremental dan hanya mengembalikan pemberitahuan yang dimodifikasi sejak tanggal ini. Untuk informasi selengkapnya, lihat Pemberitahuan - Daftar.
  • Ada dua titik akhir baru untuk mengambil atau memperbarui status pengaktifan Keamanan Tingkat Lanjut organisasi atau proyek. Kedua titik akhir mengembalikan daftar repositori dengan Keamanan Tingkat Lanjut diaktifkan. Untuk informasi selengkapnya, lihat Org - Pengaktifan atau Proyek - Pengaktifan.
  • Ada dua titik akhir baru untuk mengambil perkiraan jumlah komitter aktif Anda untuk organisasi atau proyek untuk mencerminkan perkiraan biaya penggunaan meter Keamanan Tingkat Lanjut Anda. Untuk informasi selengkapnya, lihat Perkiraan Penggunaan Pengukur Org atau Perkiraan Penggunaan Pengukur Proyek.

Izin Keamanan Tingkat Lanjut sekarang ditampilkan secara permanen

Di masa lalu, tiga bit izin Keamanan Tingkat Lanjut hanya akan ada sebagai izin yang dapat ditetapkan per repositori jika Keamanan Tingkat Lanjut diaktifkan. Sekarang, izin ini tersedia secara default di panel Izin Keamanan Repositori > dan dapat ditetapkan tanpa mengaktifkan Keamanan Tingkat Lanjut.

Cuplikan layar izin Keamanan Tingkat Lanjut.

Azure Boards

Anda memiliki dua opsi untuk menyambungkan item kerja Anda dengan permintaan atau penerapan pull GitHub. Anda dapat menggunakan sintaks AB# dalam permintaan pull, atau Anda dapat menautkannya langsung dari item kerja. Hari ini, proses ini melibatkan penyalinan URL permintaan pull GitHub dan menempelkannya saat menambahkan tautan. Ini memerlukan pembukaan beberapa jendela dan beralih antara GitHub dan Azure DevOps.

Dalam sprint ini, kami sangat senang mengumumkan pengalaman yang ditingkatkan dengan mengaktifkan fungsionalitas pencarian saat menautkan ke permintaan atau penerapan pull GitHub. Cari dan pilih repositori yang diinginkan dan telusuri paling detail untuk menemukan dan menautkan ke permintaan pull atau penerapan tertentu. Tidak perlu lagi untuk beberapa perubahan jendela dan salin/tempel (meskipun Anda masih memiliki opsi tersebut).

Gif untuk demo tambahkan tautan.

Catatan

Fitur ini hanya tersedia di pratinjau New Boards Hub.

Jika Anda tertarik untuk mendapatkan akses ke fitur ini, kirimi kami email secara langsung bersama dengan nama organisasi Anda (dev.azure.com/{nama organisasi}).

Peningkatan Hub Papan Baru

Dengan rilis ini, kami telah memperkenalkan berbagai penyempurnaan pada pratinjau New Boards Hub, yang berfokus pada aksesibilitas dan reflow halaman.

Berikut adalah contoh perubahan reflow halaman yang adaptif hingga 400% zoom.

Gif untuk demo penyempurnaan hub papan baru.

Selain itu, kami telah meluncurkan peningkatan performa di seluruh formulir item kerja, papan, dan halaman backlog. Dengan perubahan ini, Anda dapat mengharapkan Papan Baru untuk mencocokkan standar performa yang ditetapkan dengan Papan Lama.

Kontrol Pengembangan dan Penyebaran

Kami sekarang menghapus kontrol Pengembangan dan/atau Penyebaran dari item kerja, tergantung pada bagaimana proyek Anda dikonfigurasi. Misalnya, Anda dapat mengonfigurasi pengaturan proyek untuk menonaktifkan Repos dan/atau Alur.

Cuplikan layar layanan DevOps.

Saat Anda masuk ke item kerja, kontrol Pengembangan dan Penyebaran yang sesuai akan disembunyikan dari formulir.

Cuplikan layar pekerjaan terkait.

Jika Anda memutuskan untuk menyambungkan repositori GitHub ke Azure Boards, kontrol Pengembangan untuk repositori GitHub akan ditampilkan.

Cuplikan layar kontrol pengembangan .

Azure Pipelines

Federasi identitas beban kerja untuk koneksi layanan Azure Resource Manager sekarang tersedia secara umum

Pada bulan September, kami mengumumkan kemampuan untuk mengonfigurasi koneksi layanan Azure tanpa menggunakan rahasia. Sejak saat itu, banyak pelanggan telah mengadopsi fitur ini dan kami senang mengumumkan kemampuan ini sekarang tersedia secara umum.

Jika Anda belum menggunakan federasi identitas Beban Kerja, Anda dapat memanfaatkan koneksi layanan Azure bebas kekhawatiran yang tidak memiliki rahasia kedaluwarsa dengan cara berikut:

Untuk membuat koneksi layanan Azure baru menggunakan federasi identitas beban kerja, pilih Federasi identitas beban kerja (otomatis) dalam pengalaman pembuatan koneksi layanan Azure:

Cuplikan layar federasi identitas Beban Kerja (otomatis).

Untuk mengonversi koneksi layanan Azure yang dibuat sebelumnya, pilih tindakan "Konversi" setelah memilih koneksi:

Cuplikan layar tindakan Konversi.

Untuk mengonversi beberapa koneksi layanan, Anda dapat menggunakan otomatisasi misalnya, skrip PowerShell ini:

#!/usr/bin/env pwsh
<# 
.SYNOPSIS 
    Convert multiple Azure Resource Manager service connection(s) to use Workload identity federation

.LINK
    https://aka.ms/azdo-rm-workload-identity-conversion

.EXAMPLE
    ./convert_azurerm_service_connection_to_oidc_simple.ps1 -Project <project> -OrganizationUrl https://dev.azure.com/<organization>
#> 
#Requires -Version 7.3

param ( 
    [parameter(Mandatory=$true,HelpMessage="Name of the Azure DevOps Project")]
    [string]
    [ValidateNotNullOrEmpty()]
    $Project,

    [parameter(Mandatory=$true,HelpMessage="Url of the Azure DevOps Organization")]
    [uri]
    [ValidateNotNullOrEmpty()]
    $OrganizationUrl
) 
$apiVersion = "7.1"
$PSNativeCommandArgumentPassing = "Standard" 

#-----------------------------------------------------------
# Log in to Azure
$azdoResource = "499b84ac-1321-427f-aa17-267ca6975798"
az login --allow-no-subscriptions --scope ${azdoResource}/.default
$OrganizationUrl = $OrganizationUrl.ToString().Trim('/')

#-----------------------------------------------------------
# Retrieve the service connection
$getApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints?authSchemes=ServicePrincipal&type=azurerm&includeFailed=false&includeDetails=true&api-version=${apiVersion}"
az rest --resource $azdoResource -u "${getApiUrl} " -m GET --query "sort_by(value[?authorization.scheme=='ServicePrincipal' && data.creationMode=='Automatic' && !(isShared && serviceEndpointProjectReferences[0].projectReference.name!='${Project}')],&name)" -o json `
        | Tee-Object -Variable rawResponse | ConvertFrom-Json | Tee-Object -Variable serviceEndpoints | Format-List | Out-String | Write-Debug
if (!$serviceEndpoints -or ($serviceEndpoints.count-eq 0)) {
    Write-Warning "No convertible service connections found"
    exit 1
}

foreach ($serviceEndpoint in $serviceEndpoints) {
    # Prompt user to confirm conversion
    $choices = @(
        [System.Management.Automation.Host.ChoiceDescription]::new("&Convert", "Converting service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Skip", "Skipping service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Exit", "Exit script")
    )
    $prompt = $serviceEndpoint.isShared ? "Convert shared service connection '$($serviceEndpoint.name)'?" : "Convert service connection '$($serviceEndpoint.name)'?"
    $decision = $Host.UI.PromptForChoice([string]::Empty, $prompt, $choices, $serviceEndpoint.isShared ? 1 : 0)

    if ($decision -eq 0) {

        Write-Host "$($choices[$decision].HelpMessage)"
    } elseif ($decision -eq 1) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        continue 
    } elseif ($decision -ge 2) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        exit 
    }

    # Prepare request body
    $serviceEndpoint.authorization.scheme = "WorkloadIdentityFederation"
    $serviceEndpoint.data.PSObject.Properties.Remove('revertSchemeDeadline')
    $serviceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    $serviceEndpoint | ConvertTo-Json -Depth 4 -Compress | Set-Variable serviceEndpointRequest
    $putApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints/$($serviceEndpoint.id)?operation=ConvertAuthenticationScheme&api-version=${apiVersion}"
    # Convert service connection
    az rest -u "${putApiUrl} " -m PUT -b $serviceEndpointRequest --headers content-type=application/json --resource $azdoResource -o json `
            | ConvertFrom-Json | Set-Variable updatedServiceEndpoint
    
    $updatedServiceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    if (!$updatedServiceEndpoint) {
        Write-Debug "Empty response"
        Write-Error "Failed to convert service connection '$($serviceEndpoint.name)'"
        exit 1
    }
    Write-Host "Successfully converted service connection '$($serviceEndpoint.name)'"
}

Untuk informasi selengkapnya, kunjungi dokumentasi kami.

Agen Alur menunjukkan masalah pemanfaatan sumber daya secara lebih menonjol

Oktober lalu kami menambahkan kemampuan untuk melacak memori & penggunaan ruang disk oleh agen Alur.

Untuk membuat pelanggan sadar, mereka mungkin memiliki batasan sumber daya seperti keterbatasan memori atau ruang disk pada agen mereka, kami membuat batasan sumber daya lebih terlihat:

Cuplikan layar Peringatan memori terbatas dan ruang disk.

Jika Anda melihat salah satu pesan di atas, ini mungkin disebabkan oleh tugas yang menggunakan lebih banyak sumber daya daripada agen yang berdimensi yang dapat mengakibatkan agen tidak responsif dan gagal dalam pekerjaan alur:

"Kami berhenti mendengar dari agen"

Dalam kasus seperti itu, aktifkan log verbose untuk mendapatkan pesan pemanfaatan sumber daya yang lebih halus dan melacak di mana agen Anda kehabisan sumber daya. Jika Anda menggunakan agen yang dihost sendiri, pastikan agen Anda memiliki sumber daya yang memadai.

Penginstalan di luar band dari pelari tugas Node 6

Azure Pipelines menyediakan dua versi paket agen:

  • paket vsts-agent-* mendukung tugas menggunakan Node 6 untuk dijalankan.
  • paket pipelines-agent-* tidak mendukung tugas yang mengharuskan Node 6 dijalankan.

Pelanggan yang membuat agen yang dihost sendiri dapat mengunduhnya dari halaman rilis agen Alur. Versi Node yang disertakan dengan agen digunakan untuk menjalankan tugas. Lihat Versi runner node.

Setelah pendaftaran agen, agen yang diinstal dari paket pipelines-agent-* sekarang akan mengunduh versi Node yang tidak disertakan dengan agen dan tidak diblokir di bawah 'Pembatasan tugas' dalam pengaturan organisasi. Hal ini memungkinkan pelanggan untuk menggunakan paket agen pipelines-agent-* dan mengontrol penginstalan Node 6 dengan 'Pembatasan tugas' dalam pengaturan organisasi.

Persetujuan yang ditangguhkan

Persetujuan dapat digunakan untuk menandatangani penyebaran. Namun, ada situasi ketika waktu ketika persetujuan diberikan dan waktu penyebaran harus dimulai tidak cocok. Misalnya, untuk penyebaran tertentu yang Anda tinjau, Anda tahu itu di luar batas. Bayangkan itu tidak dapat segera dilanjutkan, melainkan harus berlangsung di malam hari.

Untuk mencakup skenario tersebut, kami telah menambahkan opsi untuk menunggak persetujuan untuk alur YAML. Sekarang, Anda dapat menyetujui eksekusi alur dan menentukan kapan persetujuan harus efektif.

Cuplikan layar menyetujui eksekusi alur.

Saat Anda memilih Tangguhkan persetujuan, Anda dapat mengonfigurasi waktu saat persetujuan menjadi efektif.

Cuplikan layar Tunda persetujuan.

Cuplikan layar after_approval_deferred.

Persetujuan muncul sebagai ditangguhkan di panel pemeriksaan. Setelah waktu yang ditangguhkan, persetujuan efektif.

Cuplikan layar persetujuan efektif.

Mengurutkan persetujuan dan pemeriksaan

Dengan sprint ini, Anda dapat menentukan urutan persetujuan dan pemeriksaan yang dijalankan.

Persetujuan dan pemeriksaan memungkinkan Anda mengontrol penyebaran ke produksi. Misalnya, Anda dapat menentukan bahwa hanya alur yang berjalan di main cabang repositori yang diizinkan untuk menggunakan koneksi layanan ARM produksi. Selain itu, Anda dapat memerlukan persetujuan manusia dan bahwa sistem melewati pemeriksaan performa.

Hingga hari ini, semua persetujuan, dan pemeriksaan berjalan secara paralel, kecuali untuk kunci eksklusif. Ini berarti bahwa jika proses penyebaran Anda memerlukan pemeriksaan performa untuk lulus sebelum persetujuan manual diberikan, Anda tidak dapat memberlakukan ini di Azure Pipelines. Anda harus mengandalkan instruksi persetujuan dan dokumentasi proses internal.

Dengan sprint ini, kami memperkenalkan urutan dalam Persetujuan dan Pemeriksaan. Sekarang ada lima kategori Persetujuan dan Pemeriksaan:

  1. Pemeriksaan statis: Kontrol cabang, Templat yang diperlukan, dan Evaluasi artefak
  2. Persetujuan pemeriksaan pra-dinamis
  3. Pemeriksaan dinamis: Persetujuan, Panggil Azure Function, Panggil REST API, Jam Kerja, Kueri pemberitahuan Azure Monitor
  4. Persetujuan pemeriksaan pasca-dinamis
  5. Kunci eksklusif

Cuplikan layar tambahkan pemeriksaan.

Urutan diperlihatkan juga di tab Persetujuan dan pemeriksaan.

Cuplikan layar tab persetujuan dan pemeriksaan.

Dalam setiap kategori, pemeriksaan berjalan secara paralel. Artinya, jika Anda memiliki pemeriksaan Invoke Azure Function dan pemeriksaan Jam kerja, mereka berjalan secara bersamaan.

Cuplikan layar pemeriksaan untuk penyebaran.

Periksa kategori yang dijalankan satu per satu dan jika satu gagal, sisa pemeriksaan tidak dijalankan. Ini berarti bahwa jika Anda memiliki pemeriksaan kontrol Cabang dan Persetujuan, jika kontrol Cabang gagal, Persetujuan juga akan gagal. Jadi tidak ada email yang tidak perlu akan dikirim.

Cuplikan layar pemeriksaan untuk penyebaran gagal.

Anda dapat menandatangani penyebaran setelah semua pemeriksaan dinamis berjalan, menggunakan Persetujuan pemeriksaan pasca-dinamis, atau melakukan validasi manual sebelum melanjutkan pemeriksaan dinamis, menggunakan Persetujuan pemeriksaan pra-dinamis.

Memvalidasi dan Menyimpan secara default saat mengedit alur YAML

Alur YAML yang salah dapat menyebabkan waktu dan upaya yang terbuang-. Untuk meningkatkan produktivitas pengeditan alur Anda, kami mengubah tombol Simpan di editor untuk juga melakukan validasi YAML.

Cuplikan layar tombol baru.

Cuplikan layar validasi dan simpan.

Jika alur Anda memiliki kesalahan, Anda masih dapat menyimpannya.

Cuplikan layar alur valid.

Cuplikan layar kesalahan terdeteksi.

Kami juga meningkatkan pengalaman Validasi , sehingga Anda dapat melihat kesalahan dalam daftar yang lebih mudah dipahami.

Cuplikan layar daftar kesalahan.

Azure Repos

Pencegahan bagi pengguna yang tidak sah untuk mengonfigurasi alur sebagai Kebijakan Build

Pencegahan bagi pengguna yang tidak sah untuk mengonfigurasi alur sebagai Kebijakan Build

Sebelumnya, ketika Anda telah menambahkan kebijakan build baru, Anda dapat mengonfigurasi untuk menjalankan alur apa pun dari daftar drop-down (termasuk alur yang tidak memiliki izin build Antrean ). Demikian pula, Anda dapat mengedit kebijakan build yang ada bahkan jika itu dikonfigurasi untuk menjalankan alur tempat Anda tidak memiliki izin build Antrean .

Sekarang kami mencegah pengguna melakukannya. Jika pengguna ditolak untuk Queue membangun izin untuk alur tertentu, alur tersebut akan ditampilkan sebagai dinonaktifkan (berwarna abu-abu) di menu drop-down saat menambahkan kebijakan build baru.

Lihat gambar di bawah ini memperlihatkan alur bernama "Sandbox" dengan izin build Antrean ditolak.

Cuplikan layar izin untuk Sandbox.

Lihat gambar di bawah ini memperlihatkan alur bernama "Sandbox" dinonaktifkan (berwarna abu-abu) di menu drop-down saat pengguna dengan izin build Antrean yang ditolak mencoba menambahkan kebijakan build baru.

Cuplikan layar tambahkan kebijakan build.

Ketika kebijakan build yang dikonfigurasi untuk menjalankan alur bernama "Sandbox" sudah ada, maka pengguna tanpa izin build Antrean tidak akan dapat mengedit atau melihat kebijakan build. Kasus ini ditunjukkan pada gambar berikut.

Cuplikan layar validasi build.

Ketika Anda mencoba menghapus kebijakan ini, dialog pop-up yang meminta konfirmasi penghapusan akan ditampilkan.

Cuplikan layar konfirmasi penghapusan.

Perubahan ini juga berlaku untuk panggilan API apa pun yang menghasilkan pembuatan atau pengeditan kebijakan build. Ketika salah satu tindakan ini dijalankan menggunakan identitas pengguna tanpa izin build Antrean, maka panggilan akan gagal mengembalikan kode kesalahan yang sesuai dan pesan kesalahan yang mengatakan “TFS.WebApi.Exception: TF401027: Anda memerlukan izin QueueBuild pada alur ini untuk melakukan tindakan ini.".

Penghapusan kebijakan build yang dilakukan melalui API menggunakan user identity tanpa izin build Antrean akan berhasil dan tidak akan ada peringatan atau pencegahan yang dilakukan (tidak ada perubahan dalam cara kerja penghapusan melalui API).

Azure Artifacts

Dukungan untuk Rust Crates umumnya tersedia

Mulai 16 Februari 2024, dukungan Rust Crates akan menjadi fitur yang tersedia secara umum untuk Azure Artifacts. Pengukur penagihan akan diaktifkan, menggunakan model harga yang sama yang berlaku untuk protokol lain yang didukung.

Dukungan Azure Artifacts untuk audit npm

Azure Artifacts sekarang mendukung npm audit dan npm audit fix perintah. Fitur ini memungkinkan pengguna untuk menganalisis dan memperbaiki kerentanan proyek mereka dengan memperbarui versi paket yang tidak aman secara otomatis. Untuk mempelajari lebih lanjut, Gunakan audit npm untuk mendeteksi dan memperbaiki kerentanan paket.

Langkah berikutnya

Catatan

Fitur-fitur ini akan diluncurkan selama dua hingga tiga minggu ke depan.

Buka Azure DevOps dan lihat.

Buka Azure DevOps

Cara memberikan umpan balik

Kami akan senang mendengar apa yang Anda pikirkan tentang fitur-fitur ini. Gunakan menu bantuan untuk melaporkan masalah atau memberikan saran.

Buat saran

Anda juga bisa mendapatkan saran dan pertanyaan yang dijawab oleh komunitas di Stack Overflow.

Terima kasih,

Dan Hellem