Yüz geliştirici tek bir çözüm üzerinde çalışırken geliştirme yöntemleri?

Belirli bir tarihte piyasaya sürülmesi planlanan tek bir üründe (revizyon kontrolü Git'i kullanarak) sürekli çalışan yaklaşık 200 geliştiriciden oluşan bir kuruluşuz.

Çok sayıda geliştirici nedeniyle, her ekipte yaklaşık 10 geliştirici ile "çapraz fonksiyonel" ekipler oluşturmaya çalışıyoruz, bu da kuruluşta yaklaşık 20 geliştirme ekibiyle sonuçlanıyor.

Ana depoda ürünün sürekli "yüksek standardını" (geliştirici bir çekme yaptığında, ürün en azından derlenebilir vb.) Korumak istediğimizden, bir tür kaliteli kapı kullanmak istiyoruz.

Soruyu nasıl ifade edeceğime emin değilim, ancak tek bir ürün üzerinde çalışan bu kadar büyük bir geliştirici grubu için geliştirme metodolojileri hakkında bazı tavsiyeler alabilir miyim merak ediyorum.

Görüşümüze göre, spektrumun bir ucu her geliştiricinin doğrudan ana veri havuzuna bağlanmasına izin vermektir, ancak çok sayıda geliştirici / taahhüt nedeniyle "ana veri havuzunun" sürekli olarak kırık bir aşamada olabileceğinden korkuyoruz her bir taahhüt için zorlu bir "kaliteli kapıya" sahip olamayız.

Spektrumun diğer ucu (Linus Torvalds / Linux'un bunu yaptığını düşünüyoruz), "ana havuzun" sadece üç çekme kaynağına sahip olduğu bir ağaç veya piramit yapısı gibi olabilir, bu üçünün sadece bir avuç güvenilir çekme kaynağı vb. Bununla birlikte, böyle bir yapıda değişikliklerin "ana depoya" girmek için uzun bir zincire sahip olduğunu düşünüyoruz. Ayrıca, bir birleştirme çakışması oluşursa, sorun "orijinal geliştirici" den başka bir geliştiriciye aittir.

Tüm bu arka plan bilgileri ve görüşler belirtildiğinde, birçok geliştirici için önerilen geliştirme yöntemlerini nasıl öğrenebilir ve okuyabiliriz? Büyük kuruluşlar (Microsoft, Facebook, Ubuntu, vb.) Gelişimlerini nasıl yapılandırıyor?

Ürünü, bu bileşen modüllerini bir ürün haline getiren arayüz ekipleri ile modüllere ayırmayı kesinlikle düşünmelisiniz . Bu da depoların modül bölümleme ve hiyerarşisine uyacak şekilde bölünmesi anlamına gelir. Bunu yapamayacağınız anlaşılıyorsa, proje muhtemelen katkıda bulunan geliştiricilerin sayısını göz önünde bulundurarak birleştirme kaynaklı durma noktasına öğütecektir.

Git'i sürüm kontrolü için kullanmayı planlıyorsanız, şeffaflığı artırmak ve her depo için kaliteyi sağlamak için bir kod inceleme sistemi ( Gerrit gibi ) kullanmanızı tavsiye ederim . Bu şekilde, herhangi bir yetkili veri havuzunda birleştirilmeden önce tüm çalışmaların onaylanması gerekir. Bu senaryoda, belirli güvenilir kişilere, bir kod inceleme sistemi altındaki bir repodan başka bir depoya (muhtemelen bir kod inceleme sistemi altında) gönderme izinleri vermek mantıklıdır. Doğru kullanılırsa, bu, geliştirme sürecini engellemeyen hızlı ve büyük ölçüde faydalı bir süreç olmalıdır.

Derleme doğrulaması ile ilgili olarak , amacı kodu otomatik olarak derlemek ve doğrulamak olan sürekli bir tümleştirme (CI) sunucusuna ihtiyacınız olacaktır . Kodu doğrulamakla, kodun başarıyla derlendiğini ve testlerin geçtiğini kastediyorum. Infact Jenkins (CI Sunucusu) , Gerrit doğrulama aşamasının bir parçası olarak Gerrit kod inceleme sistemine bağlanabilir ve süreci tamamen otomatikleştirebilir.

Bu entegrasyon araçlarına ek olarak, zaman birleştirmeyi en aza indirmek için geliştirme metodolojisinin bir parçası olarak sık entegrasyon için çabalamak önemlidir.

Amacı, karmaşık bir ürünü yönetilebilir ürün artışı parçalarına (Sprints denir) ayırmak olan Scrum gibi Çevik bir geliştirme sürecini düşünmeye değer olabilir . Bunlar, depolar arasında entegrasyon fırsatları sağlayacaktır.

Açıkçası, 200 kişilik bir geliştirme ekibi ile, bir çeşit hiyerarşik yapıya sahip olmalısınız. Birey veya küçük bir grup insan yazılım ürününün tasarımı hakkında kararlar almaktadır. Geliştirme süreciniz bunu yansıtmalıdır: Oluşturulan yazılımın gerçekten oluşturmak istediğiniz şeyle (kalite amaçlarıyla) eşleştiğinden emin olmak için kod incelemelerine ve testlerine ihtiyacınız vardır.

Küçük takımlar bile takımlara rehberlik etmek ve bireysel bileşenler geliştirirken çalışmalarını gözden geçirmek için liderlere ihtiyaç duyar. Takım düzeyinde de kalite kontrol süreçleri olmalıdır.

Yani, evet, depo ile ilgili hiyerarşik bir yapı izlemelisiniz. Bu, projenin genel hiyerarşik yapısıyla eşleşmektir.

Tek tek bileşenler, hepsini bir araya getirmeyi düşünmeden önce belirli bir yeterlilik seviyesine göre oluşturulmalı ve test edilmelidir. 200 kişinin doğrudan ana projeye katılmasına izin vermek kaos olacaktır. Her grup için, bireylerin projenin ana yapısını etkilemeden değişikliklerini günlük bazda yapabilecekleri ayrı alanlarınız olmalıdır.

"Değişikliklerin ana depoya girebilmek için uzun bir zinciri olması" çok iyi bir şey çünkü bu zincir kaliteyi sağlamanıza izin veriyor. Bu olabilir görünmek tüm değişiklikler hemen ana deposuna uygularsanız daha hızlı, ancak yazılımın sürekli arabası ve kullanışsız ana yapı olacak şekilde aslında bu sadece, büyük bir baş ağrısı olacaktır.

"Birleşme çatışması meydana gelirse, sorun başka bir geliştiriciye gelirse" - özellikle, bir çatışmanın nasıl çözüleceğine karar verecek olan daha üst düzey bir geliştirici olması iyi bir şeydir.

Büyük ve (sonuç olarak) yönetilemez bir şeyiniz olduğunda, çıkış yolu onu daha küçük ve yönetilebilir parçalara bölmektir.

Ekibi ve projeyi daha iyi korumanıza yardımcı olacak birkaç adım vardır:

1. işlevselliği modüllere bölme. İşlevsellik, yüksek uyum, düşük bağlaşım ve bağımlılık tersine çevirme ilkeleri kullanılarak bağımsız maksimum modüllere bölünmelidir. İlk ilke mantıksal olarak tutarlı modüller oluşturmanıza yardımcı olacaktır. İkincisi, bu modüllerin mümkün olduğunca bağımsız kalmasına yardımcı olacaktır. Üçüncüsü, bağımlı modüllerin eşzamanlı olarak geliştirilmesine yardımcı olacaktır (eğer modül A modül B'ye bağlıysa, B, B tam olarak hazır olmasa bile A'nın kullanabileceği bir arayüz sağlamalıdır).

2. açık belgelere sahip olmak. Birlikte çalışan çok fazla insan olduğunda, işler kolayca unutulabilir veya yanlış anlaşılabilir. Bu nedenle, gereksinimlerden mimari çözümlere kadar tüm belgelere özellikle dikkat etmelisiniz.

3. insanlar için görevler (asla insanlar için görevler). İşlevi daha küçük setlere böldükten sonra, bu setler üzerinde çalışmak için ekipler oluşturun. Bu aşamada ekip oluşturmak daha kolay olacaktır, çünkü her ekibin ne üzerinde çalışacağını zaten biliyorsunuzdur. Ve kod incelemeleri gibi görevler her takımın içinde yapılır.

4. açık görev sistemi. 200 geliştiricinin her biri ne üzerinde çalışılacağını açıkça bilmelidir. Bu, halihazırda ne yapıldığını, her bir insanın ne üzerinde çalıştığını ve ne kadar iş kaldığını izlemenize yardımcı olacaktır.

5. kaynak kontrolü. (Bence bu diğer cevaplarda gayet iyi anlaşılıyor)))

Ve son olarak, mümkün olduğunca basit bir takım ve modül yapısı oluşturmaya çalışın. Bu kadar büyük bir projeyle karmaşıklığı göze alamazsınız.

Hiyerarşik bir yapıya işaret eden diğer cevaplara ek olarak: bu, odaklamanın tamamen kodu hiyerarşide yukarı taşımaya ve 'hepsini bir araya getirmeye' odaklandığı zaman 'entegrasyon' noktalarını programlamanız gerektiğini ima eder. Bu, başka bir işin yapılmadığı son aşamaya sahip küçük projelerden, daha sık test ve hata düzeltmeden çok farklı değildir. Yüksek standartlar için çalışan büyük bir grupta çalıştığınız için, çoğu (zihin çerçevesi) muhtemelen zaten yerinde olacaktır.

Hotpotato'nun cevabına ek olarak (doğrudan IMHO işaretinde), önerdiğiniz gibi bazı kaynak kontrol kapılarının uygulanmasını da öneririm. Büyük bir takımı ve kod tabanını SCM için git'e taşıdığımızda, tarif ettiğiniz modele benzer şekilde "hayırsever diktatör" yöntemi olarak adlandırılan yöntemi kullanmaya karar verdik.

Bu senaryoda, tam kod tabanının kaynak dallarından düzenli olarak güncellenen birçok dalı vardır, ancak kodu daha görünür / halka açık alanlara yükseltme sorumluluğu tek bir kişiyle (veya küçük bir grup insanla) ilgilidir ve genellikle bir kod inceleme sürecine bağlı. İyi organize edilmiş bir dallanma yapısı ile, bu gerçekten iyi çalışabilir. Daha fazla bilgi için bu bağlantıya göz atın .

150M SLOC ile aynı anda yüzlerce geliştiricinin çalıştığı muazzam bir sistem üzerinde çalıştım. Bu bir anabilgisayardaydı, bu yüzden Visual Studio'dan bahsetmiyoruz, ancak ilkeler hala benimsenebilir.

Her şeyden önce, Java kullanıyorsanız, kesinlikle Maven kullanın diyebilirim. VS kullanıyorsanız, Nuget'i de kullanabilirsiniz, ancak Maven ile henüz orada olup olmadığından emin değilim (aynı zamanda biraz farklıdır). Bunun gibi bir sistem kullanmak, bağımlılıklarınızı çekmenize ve bireysel olarak çalışmalarına izin verecektir. İlgili bağımlılıkları çeken ve toplu olarak derleyebileceğiniz bir derleme komut dosyanız olur.

Doğrudan bir soru sormadığınızı, ancak bir metodoloji sorduğunuzu göz önüne alarak, önceki işverenimin bunu nasıl ele aldığını anlatacağım.

Sistem kümelere ayrıldı . Kümeler iş alanlarını ve sistem altyapı alanlarını temsil ediyordu. Onları adlandırmayacağım, ancak büyük bir perakende işi için pazarlama, perakende operasyonları, çevrimiçi işlemler, satın alma, dağıtım gibi şeyleri düşünebilirsiniz. Sistem altyapısı müşteriler ve güvenlik gibi şeyleri temsil ediyordu. Her kümede, bileşenler vardı . Önceki benzetmeyi kullanarak, örneğin, tek oturum açma, dizin hizmetleri, denetim, raporlama vb. Gibi güvenlik bileşenlerini düşünebilirsiniz. Her bileşenin içinde göreli rutinleri vardı.

Bir ad alanı veya paket olarak örneğin Organisation.Security.DirectoryServices'e sahip olursunuz. Tüm mantığı ilgili alanlarına dahil ederek, ekipler oldukça özerk bir şekilde çalıştı. Açıkçası, birden fazla takımdan girdi gerektiren büyük projeler oldu, ancak bunlar büyük ölçüde sorunsuz operasyonlardı.

Umarım bu yardımcı olur.