Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Dalam sprint ini, kami memperluas kemampuan pemeriksaan kunci eksklusif di Azure Pipelines untuk mendukung penyebaran berurutan. Sekarang Anda dapat mengantre beberapa proses pada lingkungan untuk memastikan hanya satu dari mereka dijalankan pada saat yang sama.
Lihat deskripsi fitur berikut untuk detailnya.
Azure Boards
Azure Pipelines (Alat otomatisasi alur kerja pengembangan perangkat lunak dari Microsoft)
- Dukungan untuk penyebaran berurutan daripada hanya mendukung yang terbaru saat menggunakan pemeriksaan kunci eksklusif
- Dukungan untuk ServiceNow versi Quebec
- Perubahan kebijakan pra-instalan .NET SDK pada agen Windows dan macOS yang dihosting Microsoft
- Perubahan pada tugas PublishBuildArtifacts dan DownloadBuildArtifacts
Azure Boards
Menampilkan persona yang benar pada tautan commit
Bagian pengembangan dalam item kerja menunjukkan daftar komit dan permintaan tarik yang relevan. Anda dapat melihat penulis permintaan penerapan atau pull bersama dengan waktu terkait. Dengan pembaruan ini, kami memperbaiki masalah dengan avatar penulis yang ditampilkan dengan tidak benar dalam tampilan.
Azure Pipelines (Alat otomatisasi alur kerja pengembangan perangkat lunak dari Microsoft)
Dukungan untuk penyebaran berurutan, bukan hanya yang terbaru, saat menggunakan pemeriksaan kunci eksklusif
Dalam alur YAML, pemeriksaan digunakan untuk mengontrol eksekusi tahapan pada sumber daya yang dilindungi. Salah satu pemeriksaan umum yang dapat Anda gunakan adalah pemeriksaan kunci eksklusif. Pemeriksaan ini memungkinkan hanya satu eksekusi dari alur yang dilanjutkan. Ketika beberapa eksekusi mencoba menyebarkan ke lingkungan secara bersamaan, pemeriksaan membatalkan semua eksekusi lama dan mengizinkan eksekusi terbaru untuk disebarkan.
Membatalkan eksekusi lama adalah pendekatan yang baik ketika rilis Anda bersifat kumulatif dan berisi semua perubahan kode dari eksekusi sebelumnya. Namun, ada beberapa alur di mana perubahan kode tidak kumulatif. Dengan fitur baru ini, Anda dapat memilih untuk mengizinkan semua eksekusi untuk melanjutkan dan menyebarkan secara berurutan ke lingkungan, atau mempertahankan perilaku sebelumnya untuk membatalkan eksekusi lama dan hanya mengizinkan yang terbaru. Anda dapat menentukan perilaku ini menggunakan properti baru yang disebut lockBehavior dalam file YAML alur. Nilai sequential menyiratkan bahwa semua eksekusi memperoleh kunci secara berurutan ke sumber daya yang dilindungi. Nilai runLatest menyiratkan bahwa hanya eksekusi terbaru yang memperoleh kunci ke sumber daya.
Untuk menggunakan pemeriksaan kunci unik dengan sequential penyebaran atau runLatest, ikuti langkah-langkah berikut:
- Aktifkan pemeriksaan kunci eksklusif pada lingkungan (atau sumber daya lain yang dilindungi).
- Dalam file YAML untuk alur, tentukan properti baru yang disebut
lockBehavior. Ini dapat ditentukan untuk seluruh alur atau untuk tahap tertentu:
Ditempatkan di atas panggung:
stages:
- stage: A
lockBehavior: sequential
jobs:
- job: Job
steps:
- script: Hey!
Atur pada alur:
lockBehavior: runLatest
stages:
- stage: A
jobs:
- job: Job
steps:
- script: Hey!
Jika Anda tidak menentukan lockBehavior, diasumsikan sebagai runLatest.
Dukungan untuk ServiceNow versi Quebec
Azure Pipelines memiliki integrasi yang sudah ada dengan ServiceNow. Integrasi bergantung pada aplikasi di ServiceNow dan ekstensi di Azure DevOps. Kami sekarang telah memperbarui aplikasi untuk bekerja dengan versi Quebec ServiceNow. Alur klasik dan YAML sekarang berfungsi dengan Quebec. Untuk memastikan bahwa integrasi ini berfungsi, tingkatkan ke versi baru aplikasi (4.188.0) dari Store ServiceNow. Untuk informasi selengkapnya, lihat Mengintegrasikan dengan ServiceNow Change Management.
Perubahan kebijakan pra-instalan .NET SDK pada agen Windows dan macOS yang dihosting Microsoft
Baru-baru ini, kami mengumumkan perubahan kebijakan pra-instalan .NET SDK pada agen Ubuntu yang dihosting Microsoft. Kami sekarang membuat perubahan yang sama untuk agen Windows dan macOS yang dihosting Microsoft.
Saat ini, kami menginstal semua versi .NET SDK yang tersedia dan didukung (2.1.x, 3.1.x, 5.0.x) pada agen Windows dan macOS yang dihosting Microsoft. Pendekatan ini akan diubah demi menginstal versi patch terbaru untuk setiap versi fitur. Perubahan ini dilakukan untuk memberi Anda lebih banyak ruang kosong dan untuk permintaan alat baru.
Apa artinya?
Versi SDK terdiri dari bagian-bagian berikut: x.y.znn.
z adalah versi fitur dan nn merupakan versi patch. Misalnya, untuk 2.1.302, versi fiturnya adalah 3, dan 02 adalah versi patch. Menurut pendekatan baru, kami hanya akan menginstal versi patch terbaru untuk setiap versi fitur, yaitu hanya 2.1.302 yang akan diinstal untuk 2.1.3x, hanya 2.1.403 untuk 2.1.4x dan sebagainya. Semua versi .NET SDK yang bukan versi patch terbaru akan dihapus dari gambar Windows dan macOS pada 6 September. Perubahan ini berdampak pada semua versi Windows dan macOS pada agen yang dihosting Microsoft.
Tanggal target
Penyebaran gambar yang diperbarui akan dimulai 6 September dan akan memakan waktu 3-4 hari.
Kemungkinan dampak
Jika Anda menggunakan global.json file, build Anda akan terpengaruh dalam kasus berikut:
Build Anda akan gagal jika file global.json berisi rollForward: disable properti dan versi SDK yang bukan versi patch terbaru. Contohnya:
{
"sdk": {
"version": "3.1.100",
"rollForward": "disable"
}
}
Versi .NET SDK akan secara otomatis diubah ke patch terbaru jika file global.json berisi rollForward: patch properti . Contohnya:
{
"sdk": {
"version": "3.1.100",
"rollForward": "patch"
}
}
rollForward Jika bidang tidak ditentukan dalam file global.json Anda, tidak akan ada perubahan untuk Anda. Tingkat patch terbaru yang diinstal digunakan.
Jika Anda perlu menggunakan versi .NET SDK yang tepat yang bukan patch terbaru, gunakan UseDotNet tugas untuk menginstalnya sebagai bagian dari build:
steps:
- task: UseDotNet@2
displayName: 'Use .NET Core sdk'
inputs:
version: <dotnet version>
Perubahan pada tugas PublishBuildArtifacts dan DownloadBuildArtifacts
Azure Pipelines mendukung dua set tugas untuk menerbitkan/mengunduh artefak. PublishPipelineArtifact dan DownloadPipelineArtifact adalah tugas yang lebih baru dan direkomendasikan untuk melakukan langkah-langkah ini.
PublishBuildArtifacts dan DownloadBuildArtifacts adalah tugas lama dan tidak memiliki performa dan pengoptimalan penyimpanan yang sama yang ada dalam tugas PipelineArtifact yang sesuai. Tugas-tugas lama ini juga memiliki keterbatasan skala dalam hal bagaimana mereka diterapkan. Beberapa pelanggan kami yang lebih besar telah mengalami batas ini.
Meskipun kami ingin semua pelanggan beralih ke tugas-tugas PipelineArtifact, kami juga harus mengambil beberapa langkah untuk menangani skalabilitas dari tugas-tugas BuildArtifact yang lebih lama. Sebagai bagian dari pembaruan terbaru untuk meningkatkan skalabilitas mereka, agen Azure Pipelines sekarang akan langsung berinteraksi dengan artefak build melalui domain blobstore (alih-alih merutekan melalui domain tfs). Alur ini akan mulai mengakses alamat IP dan domain yang telah lama ada di daftar izin Azure DevOps tetapi mungkin belum digunakan sebelumnya oleh alur tertentu.
Implementasi tugas BuildArtifact yang diperbarui memerlukan peningkatan agen, yang seharusnya terjadi secara otomatis kecuali peningkatan otomatis telah dinonaktifkan secara khusus atau firewall salah dikonfigurasi.
Jika agen Anda beroperasi di lingkungan yang dilindungi firewall dan tidak mengikuti instruksi tertaut, mereka mungkin mengalami kegagalan saat memperbarui agen atau dalam tugas-tugas PublishBuildArtifacts atau DownloadBuildArtifacts hingga konfigurasi firewall diperbaiki.
Gejala umum dari masalah ini adalah kesalahan mendadak yang berkaitan dengan jabat tangan SSL atau kegagalan pengunduhan artefak, sering kali terjadi pada kumpulan penyebaran yang ditargetkan oleh definisi Manajemen Rilis. Sebagai alternatif, jika peningkatan agen telah diblokir, Anda mungkin mengamati bahwa rilis menunggu agen di dalam pool yang tidak pernah datang, atau agen tersebut offline di tengah proses pembaruan mereka (yang terakhir ini terkait dengan lingkungan yang secara keliru memblokir agen CDN).
Langkah selanjutnya
Nota
Fitur-fitur ini akan diluncurkan selama dua hingga tiga minggu ke depan.
Buka Azure DevOps dan lihat.
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.
Anda juga bisa mendapatkan saran dan pertanyaan yang dijawab oleh komunitas di Stack Overflow.
Terima kasih
Aaron Hallberg