Bagikan melalui


Kepatuhan alur dan validasi keamanan - Pembaruan Sprint 141

Dalam Pembaruan Sprint 141 Layanan Azure DevOps, Anda sekarang dapat menyertakan validasi kepatuhan dan keamanan di Azure Pipelines Anda. Di Azure Repos, Anda dapat mengubah cabang target permintaan pull.

Lihat daftar Fitur di bawah ini untuk informasi selengkapnya.

Fitur

Umum:

Azure Pipelines:

Azure Repos:

Administrasi:

Langkah berikutnya

Catatan

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

Baca tentang fitur baru di bawah ini dan buka Layanan Azure DevOps untuk mencobanya sendiri.

Umum

Kembali pada bulan Juni tahun ini, kami meluncurkan iterasi pertama dari model navigasi baru kami. Kami telah menghabiskan musim panas untuk meningkatkan pengalaman tersebut berdasarkan umpan balik yang telah Anda berikan. Terima kasih! Langkah kami selanjutnya adalah beralih dari model baru menjadi pratinjau, untuk menjadi navigasi untuk produk. Silakan baca posting blog kami yang menjelaskan perubahan terbaru bersama dengan jadwal kami untuk membawa model baru ke semua organisasi.

Kami memahami pentingnya penelusuran dan menghadirkan kembali kotak pencarian yang diperluas di header produk. Selain itu, Anda sekarang dapat memanggil kotak pencarian hanya dengan mengeklik "/" di halaman layanan apa pun di Azure DevOps. Fitur ini diprioritaskan berdasarkan saran suara pengguna.

Berikut adalah kotak pencarian default:

Kotak pencarian default

Begitu mengetik "/", Anda akan melihat kotak pencarian yang diperluas:

Kotak pencarian yang diperluas

Azure Pipelines

Kepatuhan Azure Policy dan validasi keamanan di Pipelines

Kami ingin memastikan stabilitas dan keamanan perangkat lunak di awal proses pengembangan sembari menyatukan pengembangan, keamanan, dan operasi. Untuk melakukannya, kami telah menambahkan dukungan untuk Azure Policy.

Azure Policy membantu Anda mengelola dan mencegah masalah IT dengan definisi kebijakan yang menerapkan aturan dan efek untuk sumber daya Anda. Saat Anda menggunakan Azure Policy, sumber daya tetap mematuhi standar perusahaan dan perjanjian tingkat layanan Anda.

Guna mematuhi pedoman kepatuhan dan keamanan sebagai bagian dari proses rilis, kami telah meningkatkan pengalaman penyebaran grup sumber daya Azure kami. Sekarang, kami gagal dalam tugas penyebaran Grup Sumber Daya Azure dengan kesalahan terkait kebijakan yang relevan jika terjadi pelanggaran saat menyebarkan templat ARM.

Kebijakan Azure

Selain itu, kami telah menambahkan templat definisi Rilis Azure Policy. Ini akan memungkinkan pengguna untuk membuat kebijakan Azure dan menetapkan kebijakan ini ke sumber daya, langganan, atau grup manajemen dari definisi rilis itu sendiri.

templat Azure Policy

Pengiriman berkelanjutan yang disederhanakan ke Azure VM

Dalam rilis ini, kami menambahkan wizard baru untuk menyederhanakan proses pengaturan pengiriman berkelanjutan ke Azure Virtual Machines. Setelah Anda menentukan organisasi Azure DevOps dan grup penyebaran untuk mendaftarkan komputer virtual, alur rilis akan secara otomatis dibuat dengan langkah skrip sampel. Jika Anda perlu menyediakan sumber daya Azure tambahan, menjalankan skrip, meningkatkan aplikasi Anda, atau menjalankan pengujian validasi tambahan, Anda dapat dengan mudah menyesuaikan alur rilis ini.

CI ke Azure VM

Tugas Xcode mendukung Xcode 10 yang baru dirilis

Bertepatan dengan rilis Xcode 10 Apple, sekarang Anda dapat mengatur proyek untuk menyusun atau diuji secara khusus dengan Xcode 10. Alur Anda juga dapat menjalankan pekerjaan secara paralel dengan matriks dari versi Xcode. Anda dapat menggunakan kumpulan agen macOS yang dihosting Microsoft untuk menjalankan build ini. Lihat panduan untuk menggunakan Xcode di Azure Pipelines.

Xcode 10

Peningkatan performa saat mengantre build

Ketika Anda menggunakan agen yang dihosting, Anda mendapatkan VM baru untuk setiap pekerjaan. Ini menyediakan lapisan keamanan dan kontrol tambahan. Anda tidak perlu khawatir tentang build sebelumnya yang meninggalkan output atau melakukan sesuatu yang berbahaya bagi mesin. Namun, aktivitas startup pertama kali sebelumnya berarti penundaan antara saat Anda mengklik Antrekan build dan kapan alur benar-benar berjalan. Kami menyelidiki dan memperbaiki banyak penundaan ini dan sekarang melihat kecepatan 5X dalam waktu antrean-ke-mulai di seluruh kumpulan yang dihosting. Anda sekarang dapat memulai build lebih cepat, yang berarti Anda dapat melakukan iterasi lebih cepat.

Membuat koneksi layanan Azure dengan perwakilan layanan yang mengautentikasi dengan sertifikat

Sekarang Anda dapat menentukan koneksi layanan Azure di Azure Pipelines atau Team Foundation Server (TFS) dengan perwakilan layanan dan sertifikat untuk autentikasi. Dengan koneksi layanan Azure sekarang mendukung perwakilan layanan yang mengautentikasi dengan sertifikat, Anda sekarang dapat menyebarkan ke Azure Stack YANG dikonfigurasi dengan Active Directory Federation Services. Untuk membuat perwakilan layanan dengan autentikasi sertifikat, lihat artikel tentang cara membuat perwakilan layanan yang mengautentikasi dengan sertifikat.

Sambungkan dengan prinsipal layanan

Menampilkan analitik pengujian di Pipelines

Melacak kualitas pengujian dari waktu ke waktu dan meningkatkan jaminan pengujian adalah kunci untuk mempertahankan alur yang sehat. Fitur analitik pengujian memberikan visibilitas mendekati real-time ke dalam data pengujian Anda untuk build dan alur rilis. Ini membantu meningkatkan efisiensi alur Anda dengan mengidentifikasi masalah kualitas yang berulang dan berdampak tinggi.

Anda dapat mengelompokkan hasil pengujian berdasarkan berbagai elemen, mengidentifikasi pengujian utama untuk cabang atau file pengujian Anda, atau menelusuri paling detail pengujian tertentu untuk menampilkan tren dan memahami masalah kualitas seperti kelemahan.

Lihat analitik pengujian untuk build dan rilis, pratinjau di bawah ini:

Menguji analitik

Untuk informasi selengkapnya, lihat dokumentasi kami.

Azure Repos

Mengubah cabang target permintaan pull

Untuk sebagian besar tim, hampir semua permintaan pull menargetkan cabang yang sama, seperti master atau develop. Namun, dalam kasus saat Anda perlu menargetkan cabang yang berbeda, mudah untuk lupa mengubah cabang target dari default. Dengan fitur baru untuk mengubah cabang target permintaan pull aktif, ini sekarang menjadi tindakan sederhana. Cukup klik ikon pensil di dekat nama cabang target di header permintaan pull.

Mengubah cabang target

Selain memperbaiki kesalahan, fitur untuk mengubah cabang target juga memudahkan untuk "menargetkan ulang" permintaan pull ketika cabang target telah digabungkan atau dihapus. Pertimbangkan skenario saat ada PR yang menargetkan cabang fitur yang berisi beberapa fitur yang bergantung pada perubahan Anda. Anda ingin meninjau perubahan dependen dalam isolasi dari perubahan lain di cabang fitur, jadi awalnya Anda menargetkan features/new-feature. Lalu, peninjau hanya dapat melihat perubahan dan menuliskan komentar yang sesuai.

Sekarang, pertimbangkan apa yang akan terjadi jika cabang fitur juga memiliki PR aktif, dan digabungkan ke dalam master sebelum perubahan Anda? Sebelumnya, Anda harus meninggalkan perubahan dan membuat PR baru ke dalam master, atau menggabungkan PR ke dalam features/new-feature, lalu membuat PR lagi dari features/new-feature ke master. Dengan tindakan baru untuk memperbarui cabang target ini, Anda cukup mengubah cabang target PR dari features/new-feature menjadi master, mempertahankan semua konteks dan komentar. Mengubah cabang target bahkan membuat pembaruan baru ke PR yang memudahkan untuk melihat kembali perbedaan terakhir sebelum cabang target berubah.

Pembaruan cabang target

Lindungi repositori Git dengan pengaturan kompatibilitas lintas platform

Karena Git adalah teknologi lintas platform, dimungkinkan bagi file atau direktori untuk menemukan cara mereka ke sistem file di mana mereka mungkin tidak kompatibel pada platform tertentu. Anda dapat melihat detail tentang ketidakkompakan ini dalam dokumentasi kami.

Untuk membantu tim melindungi repositori mereka dan pengembangnya, kami telah menambahkan pengaturan repositori baru untuk memblokir dorongan yang berisi penerapan dengan file/direktori yang tidak kompatibel dengan satu atau beberapa platform OS. Baca selengkapnya tentang pengaturan ini.

Administrasi

Mendukung pengguna AAD di akun MSA

Azure DevOps sekarang mendukung pengguna AzureAD (AAD) yang mengakses organisasi yang didukung oleh MSA. Untuk administrator, ini berarti bahwa jika organisasi Azure DevOps Anda menggunakan MSA untuk pengguna perusahaan, Anda sekarang dapat memiliki akses karyawan baru menggunakan kredensial AAD mereka alih-alih membuat identitas MSA baru hanya untuk digunakan dengan Azure DevOps.

Kami masih percaya bahwa pengalaman terbaik adalah bagi pengguna perusahaan untuk menghubungkan Azure DevOps ke AAD, tetapi kami mempelajari awal tahun ini bahwa administrator membutuhkan lebih banyak waktu untuk melakukan konversi tersebut. Dengan mengizinkan pengguna AAD ke organisasi yang didukung MSA, pengguna baru akan dapat mengakses Azure DevOps setelah Azure DevOps mencegah pembuatan pengguna MSA baru dengan nama domain kustom yang didukung oleh AzureAD pada akhir bulan.

Untuk organisasi yang sudah menggunakan identitas AAD dengan Azure DevOps, fitur ini tidak berlaku. Untuk organisasi yang saat ini menggunakan identitas MSA, harap dicatat bahwa semua pengguna yang ada dapat terus masuk dengan identitas MSA mereka seperti yang mereka lakukan hari ini. Ini hanya berlaku untuk pengguna yang ditambahkan di masa mendatang (yang berpotensi tidak dapat membuat MSA dengan alamat email perusahaan mereka).

Berikut adalah contoh skenario di mana pengalaman ini mungkin berguna: Dorothy adalah pemilik organisasi Azure DevOps untuk perusahaannya, Fabrikam. Dia dan timnya yang terdiri dari 10 anggota tim semuanya masuk ke Azure DevOps dengan identitas MSA yang menggunakan alamat email perusahaan mereka, misalnya Dorothy@fabrikam.com. Sam adalah anggota tim baru yang bergabung dengan perusahaan hari ini. Dorothy mengundangnya ke Azure DevOps dengan menggunakan emailnya, sam@fabrikam.com. Ketika ia mengklik tautan gabung sekarang di email, ia dapat masuk ke Azure DevOps dengan identitas AAD yang sama dengan yang diberikan untuk mengakses emailnya dengan Microsoft 365. Ini memungkinkan Sam untuk berkolaborasi dengan 11 koleganya dan memberi Dorothy kebebasan untuk menghubungkan organisasi Azure DevOps-nya ke AAD ketika dia siap.

Lihat posting blog kami untuk informasi lebih lanjut.

Cara memberikan umpan balik

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

Buat saran

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

Terima kasih,

Gopinath Chigakkagari (Twitter)