Kalkınma dalları ne zaman oluşturulmalıdır?

Projemizin ekibini tek bir Ana / Gövde dalı kullanmaktan düzenli olarak Ana ile birleştirilmesi gereken birden fazla Geliştirme / İş dalına taşıyoruz. Yeni sürecimizi bu makaleye ve TFS Dallanma Kılavuzuna dayandırıyoruz (TFS ve Visual Studio 2010 kullanıyoruz).

Şu anda proje üzerinde herhangi bir anda 1 ila 5 kişi çalışmaktadır. Ana her zaman istikrarlı olmalıdır, çünkü ihtiyacımız olduğunda serbest bırakma seçeneğini istiyoruz. Sabit sprintlerimiz yok - en azından henüz - ve şu anda 1-2 haftada bir serbest bırakılıyor.

Şu anda her kişi uygulama boyunca hataları düzeltiyor. Birkaç hafta içinde uygulama için yeni bir büyük bileşen üzerinde geliştirmeye başlayacağız.

Bulduğumuz noktalardan biri gelişme dallarının ne zaman oluşturulması gerektiğidir . Geliştiricinin beceri setine bağlı olarak birden fazla kullanıcı hikayesini paralel olarak uygulayacağız. Her geliştirici için bir şube oluşturmayı düşündük, ancak bu mantıklı değil çünkü her zaman bir iş üzerinde işbirliğine ihtiyaç duyulacak. Tek bir geliştirme dalına giremeyiz çünkü diğer işler tamamlanırken Main ile birleşmek isteyeceğiz.

Kimse bu konuda rehberlik var mı?

Fred'in hata düzeltmeleri veya Harry'nin hata düzeltmeleri gibi rasgele dallara düşkün değilim. Birden fazla geliştiricinin bir özellik üzerinde çalışmasına izin veren bir (bağımsız) özellik bir dal ile çok daha rahatım; ancak özelliğin yalnızca tamamlandığında birleştirilmesi için.

Yani, şu anda sadece "bugfix" dalına ihtiyacınız var ama geliştirmeye başladıktan sonra her önemli özellik için bir dal oluşturmalısınız. Bu şekilde yapıldıklarında, diğer hata ayıklayıcı işlevlerine bağımlı olmadan birleştirilebilir ve serbest bırakılabilirler.

TFS'nin birleşmede ne kadar iyi olduğundan emin değilim ama eminim birkaç ay içinde öğreneceksiniz :)

Tek bir geliştirme dalına giremeyiz çünkü diğer işler tamamlanırken Main ile birleşmek isteyeceğiz.

Birden çok geliştirme dalının oluşturulması gerektiğini zaten biliyorsunuz . Akla gelebilecek iki senaryo:

1. Beş geliştiriciler her projede (böcek sabitleme) bağımsız bölümden üzerinde çalışıyoruz - emin bir birey şube olun edilir her geliştirici için yarattı. Bu, değişiklik kümelerinin başkalarının çalışmalarıyla çelişmediğinden emin olmak için her geliştiriciye sorumluluk ve sorumluluk yükler. Beş geliştiricinizden birinin bir hata yapması büyük olasılıktır. Böyle bir durumda / Ne zaman, diğer herkesin tutulması mantıklı değildir.
2. Çoklu özelliği gelişmeler - Ne olursa olsun, belirli bir özellik / hata üzerinde çalışan geliştiriciler sayısının, bu olmalıdır ayrılabilir. Bunun faydalı olmasının bir örneği, tüm kod taahhütlerinin geliştirilmekte olan özelliklerin bir parçası olmasıdır - ikinci bir tahmin yoktur.

DVCS ile zımni çalışma dalları

Mercurial'ı kullanıyoruz, bu yüzden geliştiriciler geliştirme kutusunda zımni iş kolu var. Taahhüt her zaman yerel çalışma alanına yapılır. Serbest bırakılabilir bir iş tamamlandığında, otomatik olarak oluşturulduğu ve test edildiği birincil repo sunucusuna gönderilir.

Neredeyse hiçbir zaman açık dallar oluşturmayız, ancak yine de sprintlerimiz asla 1 haftadan uzun değildir ve kartların tamamlanması 1-2 günden fazla sürmez.

Ayrıca, kodların diğer bölümlerinden veya diğer projelerden işte işleyerek birleştirme ağrısını azaltabilirsiniz, böylece insanlar her zaman zor birleştirme yapmak zorunda kalmazlar.

Öykü başına hem tek dal hem de sürüm başına bir dal kullandım (tüm geliştiriciler hikayelerini dev için kontrol eder ve bunlardan herhangi biri dev dalını kırarsa herkes için kırılır). Çatışmalardan hoşlanmıyorsanız, öykü başına bir dal tavsiye ederim. Geliştirici dalı, tüm geliştiriciler için her zaman sabit kalır ve başka bir geliştiricinin zaten kırdığı bir kod parçası üzerinde çalışan bir geliştiricinin bekleme süresi olmayacaktır. Hikayeniz bittiğinde, tüm kodlarınız şubenizdedir. Bunu dev ile birleştirirsiniz, ancak check-in ve test yapmazsınız, anlaşmazlık yaşarsanız onu çözersiniz ve çatıştığınız kişiden kodunu kaldırmamasını istersiniz. Sonra dev. Bu, tüm geliştiricilerin sorunsuz çalışmasına yardımcı olur. Aynı zamanda şirketin büyüklüğüne de bağlıdır. Firmamız 200 devs aynı anda çalışan bir kod tabanı, ancak hikayeleri için ayrı bir şube. Kod geliştirici dalına birleştirildikten sonra, hikaye dalı hemen silinir. Umarım bu yardımcı olur. Teşekkürler

Bu git'e dayanıyorsa, her hata düzeltmesi için bir dal oluşturursunuz, hatayı mümkün olan en kısa sürede düzeltin, hata düzeltme dalını geliştirme dalıyla birleştirin, ardından değişikliği geliştirme dalına itin. Çekme isteklerini ve birleştirmeyi gözden geçirmek en yüksek öncelik olmalıdır , çünkü bunu ne kadar çabuk yaparsanız, birleştirmenin sorun yaratma olasılığı o kadar iyi olur. Birleştirildikten sonra, bu dallar silinebilir.