Paylaşılan kütüphaneler için dallanma ve sürüm oluşturma stratejisi

Bu mesajlar birbiriyle ilişkili gibi görünüyor, ama beynim erimeye başlıyor ve bunu düşünmeye çalışıyor: P

İşverenim kaynak kontrolünü kullanmaya yeni başladı, çünkü daha fazla geliştirici işe almadan önce "depo", çoğunlukla evden çalışan yalnız geliştiricinin sabit diskiydi. Yazdığı tüm .NET kodu toplu olarak kontrol edildi ve çok sayıda yinelenen (okuma: kopyala yapıştırılan) işlevsellik var. Şu anda, SCM sistemimiz yüceltildi.

Çoğaltılan kodun bazılarını paylaşılan kitaplıklara çekmek istiyorum. Hiçbir şeyi kırmamak için orijinal repoyu yalnız bırakıyorum - mevcut kodu gerektiğinde taşıyabilir ve / veya yeniden düzenleyebiliriz. Bu yüzden sadece yeni kodlar için kütüphaneler de dahil olmak üzere bir repo oluşturdum.

Benim sorunum, bizi aşırı bir süreç içinde canlandırmadan kütüphaneleri versiyonlama etrafında dönüyor: daha tutarlı bir yaklaşıma ihtiyacımız olduğunu kabul ettik, daha fazla geliştirici çok benzer kod, yönetim ve diğer geliştiriciler bir şeyler yeniden düzenlemeye açık yazıyor, ancak muhtemelen çözüm üretkenliği etkilemeye başlarsa iyi gider.

Saplantılı zihnimdeki ideal çözüm, kütüphaneleri ayrı ayrı inşa etmek ve her bağımlı projenin kasıtlı olarak seçilen uyumlu sürümlerine karşı inşa edilmesidir. Bu şekilde, hangi istemcilerin hangi kitaplıkların hangi sürümlerine sahip olduğunu, hataları daha güvenilir bir şekilde üretebileceğini, ürünler ve kütüphaneler için bağımsız yayın dallarını koruyabildiğini ve paylaşılan kodu değiştirirken birbirlerinin projelerini kıramayacağını tam olarak biliyoruz.

Bu, özellikle evden çalışan geliştiriciler için kütüphanelerin güncellenmesini hantal hale getirir. En azından başlangıçta ortak bitleri bir araya getirirken kütüphanelerin hızlı bir şekilde değişmesini bekliyorum. Bunu tamamen düşünüyor olabilirim ve en yeni kütüphane taahhütlerine karşı her şeyi inşa etmemiz iyi olur, ancak en azından bazı bileşenlerin bağımsız olarak sürümlendirilmesi gerektiğine karar verdiğimiz güne hazırlıklı olmak istiyorum ve dağıttı. Bazı kütüphanelerin GAC'ye kurulması gerekecek olması versiyonlamayı özellikle önemli kılmaktadır.

Benim sorum şu: neyi kaçırıyorum? Tek bir çözüme sabitlenmiş gibi hissediyorum ve şimdi değişiklikler daha pürüzsüz hale getirecek varyasyonları bulmaya çalışıyorum. Bu tür bir sorunu daha önce çözmek için ne tür stratejiler kullandınız? Bu sorunun her yerde olduğunu fark ediyorum; Herhangi bir belirsizlik noktasını temizlemek ve netleştirmek için elimden geleni yapacağım.

Mercurial'ı kullanmak istediğim kadar, zaten merkezi bir ticari SCM'ye (Apps Kasası) para harcadık ve geçiş yapmak bir seçenek değil. Ayrıca, buradaki sorunun sürüm kontrol aracı seçiminden daha derin olduğunu düşünüyorum.

Ben senin inisiyatifini övüyorum. Bu, bunu uygularken kuruluş için birtakım faydalar sağlamalıdır. Kodu kopyalamak yerine taşımak istiyorum. Kopyaya sahip olmak büyük olasılıkla çözülmesi gereken uyumsuz değişikliklere neden olacaktır.

Kütüphaneler geliştikçe ve istikrar kazandıkça biraz acı olacaktır. Bu yapıldıktan sonra, faydalar gelecek. Kütüphaneye arayüzlerin aslında sözleşme ile çalışan projelerle bir sözleşme olduğunu unutmayın. Kullanılıp kullanılmadığını belirleyebildiğiniz için eski arayüzleri kaldırma avantajına sahip olabilirsiniz.

Kütüphaneler dengelenirken, yeni kütüphaneler edinmek muhtemelen kod güncelleme işleminin bir parçası olmalıdır. Kütüphane değişikliklerinin taahhütlerini planlamak isteyebilirsiniz. Taşınan kodun duyurulması, çakışan değişikliklerin azaltılmasına yardımcı olabilir.

Kütüphaneler ayrı projeler gibi ele alınmalı ve mümkün olan en kısa sürede dengelenmelidir. Stabilize olduktan sonra (özellikle arayüzler) değişiklikleri diğer projelere entegre etmek daha kolay olmalıdır. Yeni kütüphaneler eski kodlarla çalışmalıdır. Etiket kararlı kütüphane sürümleri kendi sürüm kimlikleriyle etiketlenir. Kitaplıklara üçüncü taraf kitaplıklarda olduğu gibi davranmaya çalışın.

Projeler arasında paylaşılan kod kendi başlarına proje olarak ele alınmalıdır. Üçüncü taraf kütüphanelerle aynı titizlikle ele alınmalıdır. Başka yol yok.

Grubunuzun paylaşılan kod için bir strateji benimsemesini sağlayamazsanız, şirketinizin resmi olarak kullanacağı SCM olmasa bile Mercurial veya GIT gibi modern kaynak kodu yönetim araçlarının yardımıyla kendiniz benimseyebilirsiniz. Biraz dikkatle, iki SCM aynı iş dizinini sadece birine diğerinin dahili dosyalarını yoksaymasını söyleyerek kullanabilir. Her gün uğraşmak için bir SCM, entegre etmek için ise bir SCM kullanırsınız.

Her durumda, çalışma dizininizi diğer projelerin paylaşılan kodda yaptığı değişikliklerle ne zaman güncelleyeceğinizden sorumlu olmalısınız. Bunlar sadece ortaya çıkabilecek uyumsuzluklarla başa çıkmaya hazır olduğunuzda gerçekleşmelidir; Aksi takdirde, çalışmanız yapılabilirin ötesinde kararsız hale gelebilir.

Bunları ayrı "modül" projelerine bölme yeteneğiniz varsa, bu yaklaşımı benimserim. Endişelenmeniz gereken bir şey kod bağlantısıdır. Bir yaratacak endişeleri ayrılması iyi bir uygulamadır ki, onları kırarak.

Bazı faydaları:

1. Her modülde daha basit hata ayıklama.
2. Daha hızlı oluşturma döngüleri (değişmemiş kitaplıkların yeniden oluşturulması yok)
3. Bir şey işe yaradığında, bu modülün dışındaki başka bir alanı değiştirerek onu kırma olasılığınız daha düşüktür (% 100 değil, şansınızı azaltırsınız).
4. Büyük bir birbirine bağlı karmaşa değilse iş atamalarını parçalamak daha kolaydır.
5. Bir kütüphaneyi düzelttiğinizde daha küçük parçaların daha hızlı dağıtımı (.dll / .so dosyalarına sahip olmanızın büyük bir nedeni).

Bu bölüm hakkında bir sorum var:

"Takıntılı zihnimdeki ideal çözüm, kütüphaneleri ayrı ayrı inşa etmek ve her bağımlı projenin kasıtlı olarak seçilmiş, uyumlu sürümlerine karşı inşa edilmesidir."

Tüm projeyi statik olarak bağlar mısınız? Eğer öyleyse bu aşağıdakilere yol açar: 6. Gereksiz kod şişkinliğinin azaltılması.

Bazı Negatifler:

1. Proje küçükse, sadece gerekli olmayan yere karmaşıklık eklersiniz.
2. Çok sayıda modülün dallanması, gerçekten büyük projeler için bir bakım sorununa dönüşebilir. "Kasa" bilmiyorum, bu yüzden dallanma operasyonlarının iyi mi kötü mü olduğundan emin değilim.

Şu anda, bir kerede tek bir hedefe inşa edilmiş bir kod tabanınız var gibi görünüyor. Muhtemelen beşten fazla geliştiriciniz yok. Kütüphaneleri birbirinden ayırmanın faydasını pek görmüyorum. İş akışınızı kod -> derle -> çalıştır kodla -> derle -> DLL kopyala -> derle -> çalıştır ... ick olarak değiştirirsiniz.

Bazı şirketler (Google ve Amazon), ayrı ayrı inşa edilmiş birçok ayrı kütüphaneye sahip olmanın oldukça acısız olduğu için geliştirme için yeterli altyapıya sahiptir. Ağrısız hale getirecek altyapı, SCM'nizde yaşayan (muhtemelen sahip olduğunuz) kütüphane sürümlerini belirtmenin bir yolunu, SCM'nizde yaşayan bağımlılık sürümlerini belirtmenin bir yolunu, anlamını anlayabilen ve her şeyi düzgün bir şekilde derleyebilen bir yapı sunucusu içerir ve derleme sunucunuzdan ve yerel çalışma alanınızdan uygun derleme yapılarını almanın bir yolu. Buna sahip olduğundan şüpheliyim.

Bu altyapı olmadan, aşağıdakilerden biri geçerli olduğunda projeyi ayırırdım:

• Bu kütüphaneye bağlı olarak birden fazla ürününüz veya farklı uygulamalarınız var
• Bir kerede birkaç gün boyunca sadece bu kütüphanelerde çalışıyorsunuz
• Kütüphanenin işlevselliği işle ilgili her şeyden son derece ayrıdır (örneğin, platforma özgü API'lerin etrafındaki sarmalayıcılar)
• Birleşik proje için inşa süreleri çok büyüyor

Çok fazla projeniz olduğunda ve bazılarında özel geliştiriciler ve bağımsız yayın döngüleri olduğunda bu altyapıyı oluşturmaktan endişe ediyorum.

Şimdi yapabileceğiniz ve yapmanız gereken , güvenilir, tekrarlanabilir derlemeler için bir derleme sunucusu kurmak ve belirli bir yürütülebilir dosyadan kaynak revizyonunu bulabileceğinizden emin olmaktır. .NET kullanıyor gibi görünüyorsunuz; revizyon numarası da dahil olmak üzere bir sürüm dizesi eklemek için CruiseControl.NET'i kurmak oldukça basittir.

Bir derleme sunucunuz olduğunda, bir kütüphaneyi bölmek, onu Apps Kasası'nda taşımak, CC.NET'te başka bir hedef eklemek ve ortaya çıkan DLL'yi ana projenizin kütüphane klasörüne kopyalamak ve işlemekle ilgilidir. SCM tarafında günlük geliştirmeden daha kolaydır.

Mercurial, subpozositler adı verilen bir özelliğe sahiptir. Geçenlerde Kiln'den nasıl çalıştıklarını açıklayan bu blogu okudum .

Temel olarak, projenizi bir kütüphane havuzunun belirli bir revizyonuna bağlarsınız. Bağımlı projeleri bozmadan kütüphaneyi istediğiniz kadar güncelleyebilirsiniz. Hazır olduğunuzda, kütüphanenin yeni özelliklerini projenize çekebilir ve herhangi bir kırılma ile başa çıkabilirsiniz. Farklı projeler kütüphanenin farklı revizyonlarına bağlanabilir, böylece hepsinin senkronize olması ve aynı kütüphane revizyonunu kullanması gerekmez.

Belki Apps Kasası benzer bir özelliğe sahiptir.

SC'deki her modüle, bağımlı olduğu diğer tüm modüllerin adını gösteren bir meta veri dosyası ekledik. Bir üründe, ürün için her bağımlı modülün hangi sürümünün gerekli olduğunu belirten ikinci bir meta veri dosyası bulunur. Bunun üzerine, meta veri dosyalarını analiz etmek, gerekli tüm modüllere göz atmak ve IDE'miz için bir proje oluşturmak için bir araçtır.

Bu, yapılarımızın her zaman tekrarlanabilir olmasını ve doğru başlık dosyalarının her zaman bileşenler arasında paylaşılmasını sağlar. İhtiyaç geliştikçe başka karmaşıklık da görülebilir. SC'deki tüm bağımsız modüller arasında değişen kaynak dosyaları, check-in yorumları, sürüm yorumları, yazarlar gibi bir ürünün iki yapısı arasındaki farklar hakkında raporlar oluşturabilen araçlarımız var. Kod tabanımızdan olağanüstü miktarda yeniden kullanım alıyoruz.