Etkili bir dallanma stratejisi seçin

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Team Foundation Sürüm Denetimi (TFVC) depolarınız için dallar oluşturmak, riski yalıtmak için yararlıdır. Ekip üyelerinin genellikle beş veya on kişiden fazla kişinin çalıştığı bir yazılım projesinde çalışırken karşılaştığı bazı zorlukları göz önünde bulundurun:

• Grubun, her biri makul düzeyde ayrık bir işlev kümesi üzerinde çalışan birkaç (veya belki birkaç) farklı özellik ekibi vardır. Ancak her ekip, diğer takımlar tarafından oluşturulan işlevlere de bağlıdır. Bu ekiplerin her birinde yapılan çalışmaların oluşturduğu değişikliklerin riskini yalıtmalısınız ve ancak sonunda tüm çabalarını tek bir üründe birleştirmeniz gerekir.

• Test ekibinin test etmek için kodun kararlı bir sürümüne ihtiyacı vardır ve yine de geliştiricilerin zaman zaman ürünün istikrarını bozacak yeni özelliklerle ilerlemeye devam etmesi gerekir.

• Yazılımın iki önceki sürümü ve devam eden bir geçerli sürümü vardır. Geliştirme çalışmalarının çoğu geçerli sürüme yatırım yapılsa da, önceki sürümlerin hizmet paketlerinin, kritik düzeltmelerin ve güvenlik düzeltme eklerinin ve diğer değişikliklerin zaman zaman sürümleriyle desteklenmesi gerekir.

Bu makalede doğru kararı vermenizi sağlayacak birkaç yaygın dallanma stratejisi inceleniyor.

Depo kapsamı belirlenmiş Git dallarının aksine, TFVC dalları yol kapsamına alınır ve basit değildir. Dalları yüksek ve yalnızca kod veya yayın yalıtımına ihtiyacınız olduğunda oluşturmak için çubuğunuzu ayarlayın.

Yalnızca Ana

Ek görünürlük özelliklerini etkinleştirmek için Yalnızca Ana strateji klasör tabanlı veya ana klasör Dal'a dönüştürülmüş olabilir. Değişikliklerinizi ana dala işler ve isteğe bağlı olarak geliştirme ve sürüm kilometre taşlarını etiketlerle belirtirsiniz.

RİSK: TFVC etiketleriyle geçmişin değişebilirliği ve eksikliği değişiklik denetimi riski oluşturabilir.

Temel tek dallanma stratejisiyle başlayın, stratejik olarak dallayın ve gerektiğinde daha karmaşık stratejilere dönüşmek için diğer stratejileri benimseyin.

Geliştirme yalıtımı

Kararlı bir ana dalı korumanız ve korumanız gerektiğinde, bir veya daha fazla geliştirme dallarını ana daldan dallayabilirsiniz. Yalıtım ve eşzamanlı geliştirme sağlar. Çalışmalar geliştirme dallarında özellik, kuruluş veya geçici işbirliğine göre yalıtılabilir.

Ana dalda değişiklikler olabilir. Her zaman ileriye doğru tümleştirme (FI) ana öğesini geliştirme dalı ile tümleştirin ve birleştirme çakışmalarını çözün. Ardından değişiklikleri ters tümleştirme (RI) ile main'a geri dönün. Dallar arasında aynı kalite çubuğunu koruyun. Geliştirme üzerinde derleme doğrulama testlerini (BVT' ler) ana sürümde yaptığınız gibi derleyin ve çalıştırın.

NOT: Bu stratejiyle, ekiplerin geliştirme dalını sonsuza kadar koruma olasılığı vardır ve büyük bir birleştirme bileti geçmişi oluşturma olasılığı vardır.

Özellik yalıtımı

Özellik yalıtımı, geliştirme yalıtımının özel bir türetme işlemidir ve bir veya daha fazla özellik dalını ana daldan, gösterildiği gibi veya geliştirme dallarınızdan dallandırmanıza olanak sağlar.

Belirli bir özellik üzerinde çalışmanız gerektiğinde özellik dalı oluşturmak iyi bir fikir olabilir.

Özellik çalışmasının ve ilişkili özellik dalının kullanım ömrünü kısa süreli tutun. Üst daldan yapılan ileri tümleştirme (FI) değişiklikleri sık sık. Ters tümleştirme (RI) yalnızca üzerinde anlaşmaya varılan bazı ekip ölçütleri, örneğin bitti tanımı karşılandığında üst öğeye geri döner. Ana sayfadaki özelliklerin geri alınması maliyetli olabilir ve testi sıfırlayabilir.

Yayın yalıtımı

Yayın yalıtımı, main'dan bir veya daha fazla yayın dalını tanıtır. Strateji eşzamanlı sürüm yönetimine, birden çok ve paralel sürüme ve yayın zamanında kod tabanı anlık görüntülerine izin verir.

Sürüm kilitlenmeye hazır olduğunda, sürüm için yeni bir dal oluşturmanın zamanı geldi.

Hiçbir zaman ana bilgisayardan tümleştirmeyi (FI) iletmeyin. Yayında istenmeyen değişiklikler yapılmasını önlemek için erişim izinlerini kullanarak yayın dallarını kilitleyin. Yayın dalında yapılan düzeltme ekleri ve sık erişimli düzeltmeler, ana dala ters tümleştirilebilir (RI).

NOT: Dallanma senaryolarının hiçbiri sabit değildir, bu nedenle yayın dallarında gerçekleştirilen acil durum düzeltmelerini fark edebilirsiniz. Karmaşıklığı ve ilişkili maliyeti kaybetmeden her stratejiyi gereksinimlerinize uyacak şekilde geliştirin.

Bakım ve yayın yalıtımı

Hizmet ve Yayın Yalıtımı stratejisi, hizmet dallarını tanıtır. Bu strateji, hizmet paketlerinin ve kod tabanı anlık görüntülerinin yayın zamanında eşzamanlı hizmet yönetimine olanak tanır.

Müşterilerin bir sonraki ana sürüme ve sürüm başına ek hizmet paketlerine yükseltmesi için bir hizmet modeline ihtiyacınız varsa bu stratejiyi kullanın.

Yayın yalıtımı gibi, hizmet yalıtımı ve yayın dalları da yayın kilitlenmeye hazır olduğunda oluşturulur. Hiçbir zaman ana hizmetten servise veya hizmetten sürüme tümleştirmeyi iletmeyin. Değişiklik yapılmasını önlemek için yayın dalını kilitleyin. Gelecekteki bakım değişiklikleri bakım dalında yapılabilir.

Bu yalıtım düzeyine ihtiyacınız varsa sonraki sürümler için yeni hizmet ve yayın dalları oluşturun.

Hizmet verme, düzeltme, sürüm yalıtımı

Önerilmese de, ek düzeltme dalları ve ilişkili sürüm senaryoları sunarak stratejileri geliştirmeye devam edebilirsiniz.

Bu noktada, yaygın TFVC dallanma senaryolarından birkaçını başarıyla keşfettiniz. Bir özelliğin çalışma zamanında kullanılabilir olup olmadığını belirlemek için bunları geliştirebilir veya özellik geçişi, özellikleri açıp kapatma gibi diğer stratejileri araştırabilirsiniz.

Q&A

Dallar neden kısa ömürlü olmalıdır?

Dallar kısa süreli tutularak birleştirme çakışmaları olabildiğince az tutulur.

Neden yalnızca gerektiğinde dallanmalı?

DevOps'yi benimsemek için derleme, test ve dağıtım otomasyonuna güvenmeniz gerekir. Birleştirme çakışmaları genellikle el ile müdahale gerektirdiği için değişiklik sürekli, sık ve birleştirme işlemleri daha zordur. Bu nedenle dallanmayı önlemek ve özellik geçişi gibi diğer stratejilere güvenmek önerilir.

Dallar neden kaldırılsın?

Amacınız, uzun vadeli birleştirme sonuçlarını azaltmak için değişiklikleri mümkün olan en kısa sürede main'a geri almak olmalıdır. Geçici, kullanılmayan ve bol dallar takım için karışıklığa ve ek yüke neden olur.

Kod tabanı projeler arasında dallandırılabilir mi?

Evet. Ekiplerin kaynağı paylaşması gerekmediği ve ortak bir işlemi paylaşamadığı sürece önerilmez.

Kod yükseltme stratejisi ne olacak?

Kod Yükseltme stratejisi şelale geliştirme döneminden kalma bir kalınt gibi geliyor. Genellikle uzun test döngüleri ile geliştirme ve test ekiplerini birbirinden ayırır. Strateji artık önerilmez. Bu strateji hakkında daha fazla bilgi için dallanma kılavuzuna bakın.

Geliştirmeyi ana dala birleştirirken neden hiçbir değişiklik algılanmadı?

Önceki birleştirmelerdeki değişiklikleri, örneğin çakışma çözümleme seçeneğini kullanarak keep source yoksaymış olmanız olasıdır. Bkz . Geliştirme dalı ile ana dal arasında birleştirme: Ayrıntılar için birleştirmede değişiklik yapılmadı.

TFVC ile Git dal stratejileri arasında benzerlikler var mı?

TFVC Özellik Yalıtımı dallanma stratejisi Git konu dallarına benzer.

Yazarlar: ALM'den Jesse Houwing, Marcus Fernandez, Mike Fourie ve Willy Schaub | DevOps Rangers. Onlarla buradan iletişime geçebilirsiniz.

(c) 2015 Microsoft Corporation. Tüm hakları saklıdır. Bu belge "olduğu gibi" sağlanır. URL ve diğer İnternet Web sitesi başvuruları da dahil olmak üzere bu belgede ifade edilen bilgiler ve görünümler bildirimde bulunmadan değişebilir. Kullanım riski size aittir.

Bu belge size, Microsoft ürünlerinin fikri mülkiyeti konusunda herhangi bir yasal hak sağlamamaktadır. Kendinize özgü başvuru amaçlarıyla bu belgeyi kopyalayıp kullanabilirsiniz.