Modüler bir sistemde sürüm kontrolünü kullanma stratejisi

Diyelim ki (basitlik için) istemci ve sunucu içeren bir uygulamamız var; bir havuzu hem de bir çift ayrı depo için kullanmak daha iyi bir fikir var mı?

Bunları karıştırmak muhtemelen ilişkili değişiklikleri takip etmeyi ve ilişkili dalları (yani protokol evrimi) korumayı kolaylaştıracaktır, ancak öte yandan bireysel gelişimi daha karmaşık hale getirecektir ...

Git veya mercurial kullanıyorsanız , alt modüllere veya alt depolara bakmak isteyebilirsiniz .

İstemci, sunucu ve arabirim dosyaları kendi depolarında bulunur, ancak süper havuz düzeyinde birbirine bağlanır . Bu, en üst düzeyde bir ödeme yapmanıza izin verir ve gitveya hgalt modüllerin / alt hazırlayıcıların her birinin uygun taahhüdünü kontrol eder.

Süper depoyu yalnızca hem istemci hem de sunucu birbirine uygun olduğunda taahhüt ederek, süper depo size yalnızca bir çalışma sistemini kontrol etme seçeneği sunacaktır - böylece yeni istemciyi eski bir sisteme karşı çalıştırmaya çalışamazsınız. sunucu veya tam tersi.

Alt modüller / alt depolar, ayrı bir depo kullanmanın tüm avantajlarını ve tek bir monolitik deponun avantajlarını biraz ekstra karmaşıklık pahasına sağlar.

_{Bu cevap, savunuculuk gitveyahg diğer SCMS üzerinde, sadece sadece bilmek olması umulur ki bu bu seçenek var olduğunu bilmek yeterince iyi SCMS. svnÖrneğin dışsalların nasıl çalıştığını anlamıyorum .}

Ayrı!

Aslında, biri istemci ve yalnızca karşılık gelen istemci kitaplıkları, biri Sunucu (ve karşılık gelen kitaplıklar) için ve biri paylaşılan kitaplıklar için (ikisi arasında işlevselliği gösteren API arabirimlerini içeren) üç havuz olurdu , diğer paylaşılan kodlar). Bence bu gerçekten önemli, paylaşılan kod kendi başına ayrı bir depoya gitmeli. Bu şekilde, istemciniz ve sunucunuz arasındaki birlikte çalışabilirliğin her zaman aynı sürümde olduğundan ve tüketicilerinin her birinin tasarımından izole edildiğinden emin olabilirsiniz.

Açıkçası, kullandığınız iletişim çerçevesine bağlı olarak bu her zaman mümkün değildir, ancak özel protokolünüzdeki (veya başka bir örnekte) veri aktarımı nesnelerinin biçimini veya el sıkışma adımlarını belirleyen paylaşılan kod olması muhtemeldir. .

Oldukça iyi bir Sürekli Entegrasyon ve KG kurulumuna sahip olduğunuzu varsayarsak (deneyimlerime göre oldukça büyük bir varsayım, ancak yine de yapacağım. QA departmanınız yoksa en azından CI almalısınız) Tek repo modelini olası kod yanlış eşleşmelerine karşı bir savunma olarak kullanmanız gerekmiyorsa, CI sunucunuz kitaplık ile birlikte çalışabilirliği işaretleyecek veya KG ekibiniz çalışma zamanı hatalarını yakalayacaktır (veya daha da iyisi Birim Testleriniz).

Bölünmüş depoların faydaları, bir sistemin ayrı parçalarını ayrı ayrı versiyonlama yeteneğinde yatmaktadır. Bir performans sorununun kökünü kilitlemeyi denemek için geçen haftanın Sunucusunun bir kopyasını alıp bu haftanın İstemcisi ile çalıştırmak mı istiyorsunuz? Telaşa gerek yok.

In Mercurial , bu şema kullanılarak, kullanılabilir ->anlamında olabildikleri subrepo ilişkisine:

product -> client -|-> (many components)
                   |->  shared component A

        -> server -|-> (many components)
                   |->  shared component A

Ürünün subrepos istemcisi, sunucusu var. Bunların her biri, alt ikisi olarak bileşenlerine sahiptir, muhtemelen ikisi arasında paylaşılan en az bir alt repo.

Etiketleme muhtemelen ilk iki seviyede yapılmalıdır, bunun altında değil.

Taahhütler bileşen düzeyinde yapılır, süperpozisyon, ürünün adlandırılmış dallarını ve sürümlerini etkili bir şekilde izler. Adlandırılmış dallar / yer imleri genellikle kullanılabilirlik (yani eğitilebilirlik) ve alt depolarla uyumluluk için klon dallarından daha iyidir.

hg, süperpozitlerin olduğu varsayımına yönelir . ürün ve kaydedilmesini üst düzeyinde yapılabilir, ancak birden fazla ürün aynı bileşenleri kullandığınızda özellikle iyi çalışmıyor. :-)

Git'e geçilirse bu şemanın çok değişeceğini sanmıyorum, ama henüz git'te denemedim.

Bu bir revizyon kontrol problemi değil, bir konfigürasyon yönetim problemidir. Her zaman olduğu gibi, bir çivi çakmak için bir tornavida kullanan bir programcı. Yapılandırmaları nasıl yöneteceğinizi öğrenin, revizyon kontrolü kendi kendine halledecektir.

En basit yaklaşım, tek bir depo kullanmaktır, bu nedenle karmaşıklık uğruna karmaşıklığı sevmediğiniz sürece, aksi takdirde zorlayıcı argümanların olmaması durumunda bu varsayılan seçim olmalıdır.

İstemci ve sunucu geliştirme farklı kuruluşlar tarafından gerçekleştirilecek mi? İstemcinin (veya sunucunun) birden fazla uygulaması olacak mı? İstemci açık kaynak ve sunucu uygulaması gizli mi? Tüm bu soruların cevabı "Hayır" ise, o zaman tek bir depodan daha karmaşık olan herhangi bir şeyin yararsız olması için sadece rahatsızlık getirmesi muhtemeldir.

Ayrı kod tabanlarını korumayı seçerseniz, uyumsuzluklardan ve bağımlılık cehenneminden kaçınmak için bunun nasıl uygulandığı konusunda açık politikalara ihtiyacınız olacaktır. İlk birkaç hıçkırık üzerinde çalıştıktan sonra, en güvenli şeyin her zaman iki depoyu birlikte kontrol etmek, birlikte inşa etmek ve birlikte dağıtmak olduğunu keşfedebilirsiniz ... ki bu onları ayırmanın tüm amacını bozar!

Modülerlik sahip olmak güzel bir özelliktir, ancak depoları bölmek bunu başarmak için bir araç değildir. Önceki paragrafın da ifade ettiği gibi, birden çok kod tabanına bölünen (istenmeyen) yüksek derecede birleşmiş bileşenlere sahip olabilirsiniz ve aynı şekilde aynı kod tabanında (arzu edilir) oldukça modüler bileşenlere sahip olabilirsiniz.

Birden fazla vesileyle, ekibimin mevcut git depolarını birleştirmesini (başarılı bir şekilde) savundum çünkü geliştirme ve konuşlandırmayı basitleştirdi.

Bir an için depoyu unutun. Kimseyle paylaşmasaydınız makinenizdeki iki projeyi nasıl düzenlersiniz? Ekibin geri kalanı bunu nasıl yapardı? Yapar mısın ...

• Hem istemci hem de sunucu için tüm kaynak dosyaları aynı dizine koymak?

• İstemci ve sunucu için alt dizinler içeren bir ana proje dizini mi oluşturuyorsunuz?

• İki projeyi tamamen ayrı tutuyor musunuz?

Takım olarak bu konuda fikir birliğine vardığınızda, projeleri kod deponuzda kontrol etmeye hazırsınız. Düşünebildiğim tüm revizyon kontrol araçları, istediğiniz herhangi bir dizin yapısını yeniden oluşturmaktan mutluluk duyuyor - hangi dosyanın hangi projeye ait olduğu hakkında bir parça umursamıyorlar. Ve bir veya iki (veya altı) depoya sahip olma arasındaki fark, küçük idari farklılıkların yanı sıra, genellikle o kadar büyük değildir.

Örneğin Subversion ile, istemci ve sunucu için ayrı depolar ile tek bir birleşik depo arasındaki en büyük fark, revizyon numaralarının değişme şeklidir. Tek bir depoda, istemci veya sunucuya her kod kaydettiğinizde sürüm numarası artar. Ayrı depolarda, sunucu projesine bağlılık, istemcinin ana düzeltme numarasını değiştirmez.