Akış görünümleri nedir?
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2017
Akış görünümleri, paket sürümlerinin alt kümelerini tüketicilerinle paylaşmanızı sağlar. Akış görünümlerinin yaygın kullanımları, test edilmiş ve doğrulanmış ancak hala geliştirme aşamasında olan ve/veya kalite çubuğuna uygun olan paketlerin üzerinde tutunan paket sürümlerini paylaşmaktır.
Akış görünümleri ve yukarı akış kaynakları
Akış görünümleri ve yukarı akış kaynakları, paketleri paylaşmak ve tüketmek için kurumsal düzeyde bir çözüm sağlamak üzere birlikte çalışacak şekilde tasarlanmıştır.
Diğer Azure Artifacts akışlarının akışınızı yukarı akış kaynağı olarak kullanması için, senaryoya bağlı olarak akışınızı kuruluş üyelerine veyaAzure Active Directory üyelerine yönelik görünüm görünürlüğünü ayarlayabilirsiniz.
@localGörünüm
Tüm Artifacts akışları üç görünümle gelir: @local , @prerelease ve @release . son ikisi, istediğiniz gibi yeniden adlandırarak veya silebilirsiniz önerilen görünümlerdir. @local, yukarı akış kaynaklarında yaygın olarak kullanılan varsayılan @local
Görünüm, doğrudan akışta yayımlanan tüm paketleri (örn. veya tarafından) ve yukarı akış kaynaklarından @localnuget push kaydedilen tüm paketleri npm publish@local Kullanılabilir paketlerin nasıl oluşturulmuş olduğunu öğrenmek için bkz. paket grafikleri.
Varsayılan görünüm
Akış Artifacts varsayılan bir görünüme sahip olması gerekir. Akış oluşturulduğunda varsayılan görünümünüz @local olur. Bu görünüm, diğer akışlar akışınızı yukarı akış kaynağı olarak eklerken kullanılır. Yukarı akış kaynaklarının görünüm kullanımını neden gerekli k olduğu hakkında daha fazla bilgi edinmek için paket grafları makalesine göz atabilirsiniz.
Not
Akış görünümleri salt okunurdur, yani bir görünüme bağlı kullanıcılar yalnızca bu görünümde yayımlanan paketleri ve/veya yukarı akış kaynaklarından daha önce kaydedilen paketleri kullanabilir.
Paketleri serbest bırakmak için akış görünümlerini kullanma
Sürekli tümleştirme ve teslim senaryolarında paketler oluştururken üç bilgiyi iletmek önemlidir: değişikliğin doğası, değişiklik riski ve değişikliğin kalitesi.
Değişikliğin doğasını ve riskini değerlendirme
Hem değişikliğin doğası hem de riski, değişikliğin kendisiyle ilgili, yani yapmak üzere ayarlığı yapılan şey, her ikisi de çalışmaların başlangıcında bilinir. Yeni özellikler sunuyorsanız, mevcut özelliklerde güncelleştirmeler yapıyor veya hatalara düzeltme eki uygulama; Bu, değişikliğinizin doğasıdır. Hala uygulamanın API bölümünde değişiklik yapıyorsanız; Bu, değişikliğinizin riskiyle ilgili bir durum. Çoğu NuGet, bu iki bilgiyi iletmek için Semantik SürümLeme (SemVer) notalarını kullanır. SemVer yaygın olarak kullanılan bir standarttır ve bu tür bilgileri iletişim kurmak için iyi bir iş yapar.
Değişikliğin kalitesini belirleme ve iletişim kurma
Değişikliğin kalitesi, doğrulama işlemi tamamlandıktan sonra genel olarak bilinmemektedir. Bu, değişikliğiniz hazır olduktan ve paketledikten sonra gelir. Bu ayrıntı nedeniyle, paketleme sırasında ve doğrulamadan önce belirtilen sürüm numarasında kaliteyi iletemezsiniz. Önceden doğrulamaya yönelik geçici çözümler vardır (örneğin, derlemenin URL'lerini paketten önce doğrudan tüketin ve paketleri bir "hata ayıklama" veya "CI" ortamında yayımlayın, ardından bu paketleri bir "yayın" ortamında doğrulayın ve yeniden yayımlayın) ama yerleşik paketin doğru kalite standardını karşılayana kadar hiçbir şey garanti edilemez.
@Release görünümler, doğrulandıktan sonra bir paketin kalitesini iletişim kurmanızı sağlar. CI/CD'de paket sürümünü kullanarak değişikliklerinizin doğasını ve riskini ileten SemVer uyumlu paketler oluşturun, sonra belirli bir kaliteye sahip olduğunu (örneğin, @prerelease , vb.) tüketicilerine göstermek için paketi bir yayın görünümüne @release yükseltin. Bu nedenle bir sürüm görünümü, tüketicinizin yalnızca test edilen, doğrulanmış ve kullanıma hazır olan her paketin sürümlerinin alt kümesini görmelerini sağlar.
