Share via

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.

Screenshot of Select a geography.

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.

Screenshot of case-sensitive middleware path.

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.

Screenshot of secret alerts list.

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.

Screenshot of code scanning alerts list and severity filter.

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.
  • GET SARIFs API sekarang mengembalikan kesalahan unggahan tertentu untuk membantu Anda memecahkan masalah kegagalan unggahan SARIF. Untuk informasi selengkapnya, lihat SARIF.
  • 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.

Screenshot of Advanced Security permissions.

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 to demo add link.

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 to demo new boards hub improvements.

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.

Screenshots of DevOps services.

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

Screenshots of related work.

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

Screenshots of development control .

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:

Screenshot of Workload identity federation (automatic).

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

Screenshot of Convert action.

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:

Screenshot of Limited memory and disk space warning.

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.

Screenshot of approve a pipeline run.

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

Screenshot of Defer approval.

Screenshot of after_approval_deferred.

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

Screenshot of approval is effective.

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

Screenshot of add check.

Urutan ditampilkan juga di tab Persetujuan dan pemeriksaan.

Screenshot of approvals and checks tab.

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

Screenshot of checks for deploy.

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.

Screenshot of checks for deploy fail.

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 sia-sia. Untuk meningkatkan produktivitas pengeditan alur Anda, kami mengubah tombol Simpan di editor untuk juga melakukan validasi YAML.

Screenshot of new button.

Screenshot of validate and save.

Jika alur Anda memiliki kesalahan, Anda masih dapat menyimpannya.

Screenshot of pipeline is valid.

Screenshot of errors detected.

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

Screenshot of errors list.

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.

Screenshot of permissions for 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.

Screenshot of add build policy.

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.

Screenshot of build validation.

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

Screenshot of confirm deletion.

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

Make a suggestion

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

Terima kasih,

Dan Hellem