Şirketimin şubeleri birleştirmesi yanlış mı?

Son zamanlarda dallanma ve birleşme ve SCM ile ilgili bir MSDN makalesine rastladım: Dallanma ve Birleşme Astarı - Chris Birmele .

Makalede 'Büyük Patlama Birleşmesi' bir birleşme kaymazı olduğunu söylüyorlar:

Big Bang Merge - gelişme çabasının sonuna kadar birleşen ve tüm şubeleri aynı anda birleştirmeye çalışan erteleniyor.

Bunun, şirketimin üretilen tüm geliştirme dalları ile yaptıklarına çok benzer olduğunu anladım.

Son inceleme + gövde birleştirme otoritesi olarak görev yapan bir kişiyle çok küçük bir şirkette çalışıyorum. 5 geliştiricimiz var (ben dahil), her birimize ayrı bir görev / hata / proje verilecek ve her birimiz mevcut bagajdan (yıkılma) ayrılacak ve daha sonra şubemizdeki geliştirme çalışmasını gerçekleştireceğiz, sonuçları test edeceğiz, belgeler yazacağız. Gerekirse, diğer geliştiricilerle bir eş inceleme ve geri bildirim döngüsü gerçekleştirin ve ardından şubeyi proje yönetimi yazılımımızda gözden geçirme + birleştirme için gönderin.

Gövde deposundaki tek otorite olan patronum, şubelerin incelemelerini erteleyebilecek kadar kısa bir süre içinde erteleyecek, bazı şubeler geliştirme / düzeltmeler için geri çekilecek. şubeler hemen bagajda birleşecek, bazı şubeler çatışmalar vb. yüzünden geri atılacak

Son gözden geçirme kuyruğunda oturan 10-20 aktif dalın bagajda bir araya gelmesi bizim için alışılmadık bir durum değil.

Aynı zamanda, son gözden geçirme ve birleştirme aşamasındaki uyuşmazlıkları da sık sık çözmeliyiz çünkü aynı dalda iki dal oluşturulmuş ancak aynı kod parçasını değiştirmiştir. Genellikle bunu, sadece bagajın üstünü yeniden açarak ve değişikliklerimizi yeniden uygulayarak ve çatışmaları çözerek ve ardından yeni şubeyi incelenmek üzere göndererek önleriz.

Sahip olduğum bazı doğrudan sorular:

• 'Büyük patlama birliği' olarak tanımlanan anti-paterni sergiliyor muyuz?
• Bu birleştirme işleminin bir sonucu olarak gördüğümüz sorunlardan bazıları mı?
• Patronumdaki darboğazı artırmadan bu birleştirme sürecini nasıl geliştirebiliriz?

Düzenleme: Patronumun gövde deposundaki tutuşunu gevşeteceğinden veya diğer cihazların gövdeyle birleşmesine izin vereceğinden şüpheliyim. Bunun sebeplerinin ne olduğundan emin değilim ama konuyu gündeme getirmeyi planlamıyorum çünkü daha önce gündeme getirildi ve oldukça hızlı bir şekilde düşürüldü. Bence bize güvenmiyorlar, bu hiç mantıklı değil çünkü her şey zaten izleniyor.

Bu durumla ilgili herhangi bir başka görüş memnuniyetle karşılanacaktır.

Bazı öneriler:

• Her dalda yapılan değişiklikler yeterince küçük olduğu sürece, sonuçta ortaya çıkan birleştirme çakışmalarını etkili bir şekilde halledebildiğiniz sürece, birçok özelliğe veya hata düzeltme dalına sahip olmanın yanlış bir tarafı yoktur. Çalışma şekliniz iyi değilse, bazı MSDN makaleleri bu sizin kriteriniz olmalıdır.

• Her ne zaman bir dal bagajda birleştiğinde, bagaj en kısa sürede tüm açık gelişim dallarında birleştirilmelidir. Bu, ekipteki bütün kişilerin birleşme çatışmalarını kendi branşlarına paralel olarak çözmelerini ve böylece bagajın bekçisinden bir miktar yük almasını sağlar.

• Eğer kapı bekçisi 10 şube "gövdeyle birleşmeye hazır" olana kadar beklemeyecekse bu daha iyi işe yarar - son gövde entegrasyonlarından birleşme çatışmalarını çözmek her zaman ekip için biraz zamana ihtiyaç duyar, bu nedenle iç içe geçmiş zaman aralıklarında çalışmak daha iyi olur - kapı bekçisi tarafından bir entegrasyon, biri ekip tarafından yeniden birleştirme, kapı bekçisi tarafından bir sonraki entegrasyon, daha sonra ekip tarafından yeniden birleştirme vb.

• Dalları küçük tutmak için, daha büyük özellikleri birkaç küçük göreve bölmeye ve bu görevlerin her birini kendi dalında geliştirmeye yardımcı olabilir. Özellik, tüm alt görevler uygulanana kadar üretime hazır değilse, tüm alt görevler tamamlanana kadar onu bir özellik geçişinin arkasındaki üretimden gizleyin .

• Er ya da geç, kod tabanındaki birçok dosyayı etkileyen yeniden düzenleme görevleriyle karşılaşırsınız - bunların çoğu dalla çok fazla birleştirme çatışmalarına neden olma riski vardır. Bunlar en iyi şekilde takımda açıkça iletişim kurarak ele alınabilir ve bunları tam olarak yukarıda yazdığım şekilde kullandığınızdan emin olun: yeniden entegrasyondan önce ilk önce tüm dev branşlarına entegre ederek ve daha küçük alt refaktörlere bölerek.

• Mevcut takım büyüklüğünüz için tek bir bekçi bulundurmak hala işe yarayabilir. Ancak, takımınızın boyutu büyüyecekse, ikinci bir bekçi (veya daha fazla) sahibi olmanın yolu yoktur. Not Herkesin bagajda birleşmesine izin vermeyi önermiyorum, ancak bu sadece patronunuzun bunu yapabileceği anlamına gelmez. Kapı bekçisinin işini yapmak için aday olabilecek bir ya da iki üst düzey dev vardır. Ve şimdiki takımınızın büyüklüğü için bile, ikinci bir bekçi, takımınızın bagaja daha sık ve daha erken veya patronunuz müsait olmadığında entegrasyonunu kolaylaştırabilir.

'Büyük patlama birliği' olarak tanımlanan anti-paterni sergiliyor muyuz?

Kulağa benziyor.

Bu birleştirme işleminin bir sonucu olarak gördüğümüz sorunlardan bazıları mı?

Kesinlikle

Patronumdaki darboğazı artırmadan bu birleştirme sürecini nasıl geliştirebiliriz?

Benim şirketimde her dev birleşme yeteneğine sahip. Her iki taraf da memnun kalana kadar gözden geçirme / geri bildirim / güncelleme döngüsünden başka bir geliştiriciye bir Birleştirme İsteği atarız. Ardından gözden geçirici kodu birleştirir.

Birleşmeyi bekleyen 10-20 şube, sürecinizin hatalı olduğuna dair bir işarettir. Eğer bu kadarı olsaydık, bütün dev çalışmaları temizlenene kadar dururdu.

Bu esasen, uçuş sırasında herhangi bir zamanda yaptığınızdan çok daha fazla şubesi bulunan ve özellikle de Linux çekirdeği dahil birçok açık kaynaklı projenin nasıl çalıştığıdır. Bu projelerde büyük patlamaların birleşmesinden kaçınmanın tipik yolu, sürekli entegrasyon için başka bir şube (veya çoklu dallar) oluşturmaktır. Bu, değişikliklerin iş arkadaşlarınızla birlikte çalıştığından emin olmak için kullandığınız daldır ve kapı bekçisi inceleme yapmak için etrafa geldiğinde periyodik olarak bagaja yeniden yerleştirilir.

İsteğe bağlı olarak, bu dalı kendi patronu taleplerinizden birçoğunu patronunuzun incelemesi için büyük bir tutarlı istekte birleştirmek için kullanabilirsiniz. Linus Torvalds tipik olarak iki veya daha fazla seviye derinlemesine entegre edilmiş çekme istekleri alır ve örneğin tam bir yeni dosya sistemi sürücüsü siparişinde bir boyuta sahip olabilir.

Her iki Doktor Brown ile aynı fikirdeyim ama aynı zamanda başka bir antipattern görüyorum:

Patronum, gövde depo üzerinde tek otorite , aslında edecek erteleme tüm değerlendirme elinden kadar, bazı dalları geliştirmeleri / düzeltmeler için geri atılır gibi zaman içinde tek bir noktaya kadar dalların o bazı değerlendirmeleri gerçekleştirecektir nerede şubeler hemen bagajda birleşecek, bazı şubeler çatışmalar vb. yüzünden geri atılacak

Benim düşünceme göre bazı yönetim antipatterns vardır:

1. Takımın hızını kısıtlayan tek boğulma noktasıdır. Sizin otobüs faktörü 1'dir kısıtlar teorisi sen zincirinin en yavaş parçası iyileştirmede çaba gerektiğini söylüyorlar.
2. Yöneticiniz geribildirim döngüsünü yavaşlatıyor ve ekibinizin çevikliğini azaltıyor. Her hafta salıverir misin?
3. Birleşmelerin karmaşıklığı, kod miktarı ile birlikte katlanarak büyür. 100 çizgiden 10 çizgiyi, 1000 çizgiden 1'den daha iyidir. Bu en kısa zamanda yapmanız gereken nedenlerden sadece biri.
4. Bagajda bir arıza tespit ederseniz, zaman içinde daha sonra yaparsınız. Hangi branşlardan hangisi sorunlu
5. Kararlar, onlar hakkında daha fazla düşünen kişiler tarafından yapılmalıdır. Bu durumda kim daha fazla bilir? İddiaya girerim kodu yapan geliştiriciler.
6. Yöneticiniz bayramlarda ise üretimdeki bir hatayı düzeltemezsiniz.
7. İşi tekrar yapıyorsun ve şubeleri geri atıyorsun. Bu zaman kaybı . Üretime ulaşmak için beklediği zaman da boşa.

Tavsiyeler:

• Yöneticinizin sorumluluğu takıma devretmesi gerekir. Takımın olgun ve profesyonel olduğunu göstermelisin. Takıma güvenebileceklerini açıkça belirtin
• Bazı inceleme yöntemlerini uygulayın. Diğer iki ekip üyesinin onayına ihtiyacınız olabilir.
• SVN kullanıyor olması zorlaştırıyor. Git'i deneyin ve size yardımcı olup olmadığına bakın. Hatta daha fazla. GitHub kullanıyorsanız Çekme İsteği mekanizmasını kullanabilirsiniz, böylece bir birleştirme belirli oylar gerektirir.
• Çevik uygulamalar, sürekli entegrasyon ve DevOps hakkındaki bilgileri okuyun ve paylaşın.

Ayrı dallarda özellik çalışması yaptığınızda, dallardan biri gövdeye birleştirilip diğer özellik dallarına çekilene kadar herhangi bir entegrasyon testini kolayca yapamazsınız. Tecrübelerime göre, bu Big Bang Merge anti-pattern'indeki ana problem. İdeal olarak, özellik çalışması yaparsınız, özellik dalında test eder, bagajda birleştirirsiniz ve bu noktada bu özellik ile yapılırsınız. Birleştirilmemişse, başka bir şey ondan önce bagaja birleştirildiğinde tekrar ziyaret etmeniz gerekir. Bu anti-paternin acısı, geliştirme döngüsünün sonunda ortaya çıkan bir çok entegrasyon tipi hataya sahip olmanızdır.

Demek 20 şuben var. Şube 1 yeni birleştirildi. Daha sonra, dal 2'nin geliştiricisi, dal 1'i, dallar olmadan ana dalda birleşmeden önce birleştirmek için dallarında birleştirmelidir. Daha sonra, dal 3'ün geliştiricisi, dal 1'i ve dal 2'yi dallarında birleştirmek zorundadır, sonra çatışmasız olarak ana birimde birleşebilir, sonra birleşir.

Okuyucu için Alıştırma: Yazımın tamamını basan bir program yaz :-)

Bu delilik. Birleşmek için inanılmaz miktarda zaman harcayacaksınız.

Çalışma şekliniz ve patronunuzun sorumlu bir kontrol manyağı olduğu göz önüne alındığında, branşlaşmanın kendisi sorun gibi görünüyor. Her özellik için bir dal oluşturmak yerine, her geliştiricinin özelliğini parça olarak doğrudan bagaja koymasını isteyin. Bu, geliştiriciye entegrasyon yükünü daha küçük adımlarla (kazan-kazan) getirir. Kapı bekçisi, geliştirme döngüsünün başında daha uzun bir süre boyunca daha küçük değişiklikleri izlemeye devam edebilir ve hala ana inceleme uzmanı olabilir.

Dallanma, yapmak için çok iyi bir nedeniniz yoksa veya başka bir seçeneğiniz yoksa, yapmak istemediğiniz bir şeydir. İşleri daha sıkı senkronize etmek için yeterince küçüksünüz, bu daha kolay ve daha güvenli olacaktır.