Dallanma kaynak kodu ve uygulama yaşam döngüsü ile en iyi uygulama

Biz küçük bir ISV mağazasıyız ve genellikle her ay ürünlerimizin yeni bir sürümünü gönderiyoruz. Subversion'u kod depomuz olarak ve Visual Studio 2010'u da IDE olarak kullanıyoruz. Birçok insanın Mercurial ve diğer dağıtılmış kaynak kontrol sistemlerini savunduğunun farkındayım, ancak bu noktada bunlardan nasıl faydalanabileceğimizi göremiyorum, ama yanılıyor olabilirim.

Ana sorunumuz, dalları ve ana gövdeyi nasıl senkronize tutmaktır.

Bugün işleri şu şekilde yapıyoruz:

1. Yeni sürümü yayınla (Subversion'da otomatik olarak bir etiket oluştur)
2. Gelecek ay piyasaya sürülecek ana gövde üzerinde çalışmaya devam et

Ve döngü her ay tekrarlanır ve mükemmel çalışır. Sorun, acil bir hizmet sürümünün serbest bırakılması gerektiğinde ortaya çıkar. Ağır gelişmekte olduğu ve acilen serbest bırakılacak kadar stabil olmadığı için ana gövdeden (2) serbest bırakamayız.

Bu durumda aşağıdakileri yaparız:

1. 1. adımda oluşturduğumuz etiketten bir şube oluşturun
2. Hata düzeltme
3. Test ve serbest bırakma
4. Değişikliği ana gövdeye geri itin (varsa)

En büyük sorunumuz bu ikisini birleştirmek (ana dalla). Çoğu durumda otomatik birleştirmeye güvenemeyiz, çünkü:

• ana bagajda çok fazla değişiklik yapıldı
• Karmaşık dosyaları (Visual Studio XML dosyaları vb. gibi) birleştirmek çok iyi çalışmıyor
• başka bir geliştirici / ekip anlamadığınız değişiklikler yaptı ve onu birleştiremezsiniz

Yani bu iki farklı sürümü (şube ve ana) senkronize tutmak için en iyi uygulama. Ne yaparsın?

Bence dallanma ve birleştirme için yaklaşım tamam, ama asıl sorun kod tabanı oldukça kararsız olmasıdır, odaklanmak ve en aza indirmek için gereken budur.

Sağlanması gereken ilk şey, kod tabanının endişelerin iyi bir şekilde ayrılmasıdır . Çeşitli bileşenler arasındaki bağımlılıkların izole edilmesi ve azaltılması gerekir. Bu, sorunlarınızın çoğunu çözmelidir. Ayrıca tek sorumluluk ilkesi gibi uygulamaları takip etmek de yardımcı olacaktır.

Büyük bir mimari değişikliğin meydana gelmesi gerekiyorsa, kendi dalında gerçekleşmeli ve daha sonra tamamen test edilmiş ve 'istikrarlı' (ana nedenlerle) bir kez ana haline getirilmelidir. Bu acı verici ve zorlayıcı olabilir, ancak nadir de olmalıdır. İyi test uygulamalarınız varsa risk en aza indirilir.

Ayrıca dağıtılmış bir sürüm kontrol sistemine geçmek de yardımcı olabilir. Bu, hazır olduklarında farklı dallardan birleştirilen farklı özelliklere sahip istikrarlı bir gövde vermelidir. Kod çok bağımlıysa yine de birleştirme olur, ancak daha fazla kontrole sahip olursunuz.

Buna başka bir açıdan bakıldığında, ekibiniz arasında artan iletişimi de düşünün. Düzenli çevik tarzda standup toplantıları yapın. Ekip üyelerinin nerede oturduklarını ve bunun nasıl yardımcı olabileceğini düşünün. Karmaşık bir birleşmenin gerçekleşmesi gerekiyorsa, o kadar da kötü bir şey olmayabilir - her iki tarafa da anlayış sağlayacak bir çift programlama yaklaşımı kullanın.

Buna tam tersi bir şekilde bakma eğilimindeyim:

• Bagaj her zaman üretime hazır kod olmalıdır (ilk ilk sürümünüzden sonra, yani).
• Aylık gelişiminizin gerçekleştiği, gövdeye paralel çalışan bir geliştirme tipi şube olmalıdır. Serbest bırakma zamanı geldiğinde her ay, bu bagajda birleştirilir, test edilir ve sonra serbest bırakılır.
• Düzeltmeler daha sonra bagajınızda kolayca yapılabilir ve check-in yapabilir ve her zaman başarıyla dağıtılabilir. Daha sonra düzeltmeden bir yama yapın ve geliştirme dalınıza uygulayın.

Tabii ki, bu iş akışı SVN olmayan bir şey için çok daha uygundur, çünkü iyi dallanma ve birleştirme, iş akışınıza bakılmaksızın SVN'de oldukça acı verici bir şeydir. Deneyimlerime göre, SVN'de birleştirme neredeyse her zaman manuel olarak yapılmalıdır, çünkü işe yaramaz ve bunun çevresinde gerçek bir yol yoktur.

Son zamanlarda, bir sonuç olarak "dallanma ve birleşme" felsefesini savunuyorum. Bence şubelerden kod birleştirme ile uğraşmak teknik bir sorun değil, ama bilişsel olarak zor bir görev: Dahası, henüz dallanma ve birleşmenin pratikte gerçekten işe yaradığını görmedim. Kod bir kez dallandığında, deneyim bana kodu birleştirme sorunu olmaktan başka bir şey olmadığını söyler.

Disiplinli bir serbest bırakma yaklaşımı iyi sonuç verir.

SVN şubesi esnek olacak şekilde tasarlanmamıştır. İlk probleminizin SVN'de yatmasını öneririm; bundan hareket etmek yeni seçenekler açacaktır.