Apa itu tampilan umpan?
Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019
Tampilan umpan memungkinkan pengembang berbagi subset versi paket dengan konsumen mereka. Penggunaan umum tampilan umpan adalah berbagi versi paket yang telah diuji dan divalidasi tetapi menahan paket yang masih dalam pengembangan dan/atau tidak memenuhi bilah kualitas tertentu.
Tampilan default
Semua umpan Artefak dilengkapi dengan tiga tampilan: @local, @prerelease, dan @release. Dua yang terakhir adalah tampilan yang disarankan yang dapat Anda ganti nama atau hapus sesuai keinginan. @local adalah tampilan default yang umumnya digunakan dalam sumber hulu.
Tampilan @local berisi semua paket yang diterbitkan langsung ke umpan dan semua paket yang disimpan dari sumber hulu.
Tampilan umpan bersifat baca-saja, yang berarti bahwa pengguna yang tersambung ke tampilan hanya dapat menggunakan paket yang diterbitkan ke tampilan tersebut dan/atau paket yang sebelumnya disimpan dari sumber upstream. Lihat grafik paket untuk mempelajari bagaimana paket yang tersedia dibangun.
Catatan
Azure Artifacts hanya mendukung penerbitan dan pemulihan paket dari dan ke tampilan default - @Local.
Tampilan umpan dan sumber hulu
Tampilan umpan dan sumber hulu dirancang untuk bekerja sama untuk menyediakan solusi tingkat perusahaan untuk berbagi dan menggunakan paket. Agar umpan Artefak Azure lainnya dapat menggunakan umpan Anda sebagai sumber hulu, Anda harus mengatur visibilitas umpan kepada anggota organisasi Anda, atau anggota ID Microsoft Entra Anda, tergantung pada skenario Anda. Jika Anda memilih yang terakhir, semua orang di organisasi Anda akan dapat mengakses umpan Anda. Selain itu, semua umpan di organisasi Anda dan organisasi lain yang terkait dengan penyewa Microsoft Entra yang sama akan dapat di hulu ke umpan Anda.
Catatan
Semua tampilan umpan dalam proyek publik dapat diakses oleh semua orang di internet.
Paket rilis dengan tampilan umpan
Saat membuat paket rilis, penting untuk menyampaikan tiga informasi: sifat perubahan, risiko perubahan, dan kualitas perubahan.
Sifat dan risiko perubahan
Sifat dan risiko perubahan keduanya berkaitan dengan perubahan itu sendiri, yaitu, apa yang Anda tetapkan untuk dilakukan, mereka berdua dikenal pada awal pekerjaan. Jika Anda memperkenalkan fitur baru, membuat pembaruan untuk fitur yang ada, atau menambal bug; ini adalah sifat perubahan Anda. Jika Anda masih membuat perubahan pada bagian API aplikasi Anda; ini adalah salah satu aspek risiko perubahan Anda. Banyak pengguna NuGet menggunakan notasi Semantic Versioning (SemVer) untuk menyampaikan dua informasi ini. SemVer adalah standar yang banyak digunakan dan melakukan pekerjaan yang baik untuk mengkomunikasikan jenis informasi ini.
Kualitas perubahan
Kualitas perubahan umumnya tidak diketahui sampai proses validasi selesai. Ini datang setelah perubahan Anda dibangun dan dibungkus. Karena detail ini, tidak layak untuk mengomunikasikan kualitas perubahan segmen numerik dari nomor versi (misalnya 1.2.3). Ada solusi untuk memvalidasi sebelumnya (misalnya, mengonsumsi DLL build secara langsung sebelum paket dikemas dan menerbitkan paket ke lingkungan "debug" atau "CI" kemudian memvalidasi dan menerbitkan ulang paket tersebut ke lingkungan "rilis") tetapi tidak ada yang telah kita lihat yang benar-benar dapat menjamin bahwa paket bawaan akan memenuhi standar kualitas yang benar.
Anda dapat menggunakan @Release tampilan sebagai sarana untuk menyampaikan kualitas perubahan Anda. Dengan menggunakan tampilan, @Release Anda dapat berbagi paket yang memenuhi bilah kualitas Anda dan memungkinkan konsumen Anda untuk hanya melihat subset versi paket yang diuji, divalidasi, dan siap digunakan.
