“Bağımlılık yönetimi” için nasıl dava açabilirim?

Şu anda yapılar için bağımlılık yönetimini benimsemeye çalışıyorum (ala Maven, Ivy, NuGet) ve bir düzineden fazla kurumsal genişliğe sahip olan paylaşılan modüller için bir iç havuz oluşturuyorum. Bu yapım tekniğinin ana satış noktaları nelerdir? Şimdiye kadar olanlarım:

Paylaşılan modüllerin, özellikle sürüm yükseltmelerinin dağıtılması ve içe aktarılması işlemini kolaylaştırır.
Paylaşılan modüllerin bağımlılıklarının tam olarak belgelenmesini gerektirir.
Paylaşılan modülleri kaynak denetiminden, hızlandırmadan ve çıkışları / check-in'leri basitleştirmeden kaldırır _{(20+ kitaplık içeren uygulamalarınız olduğunda bu gerçek bir faktördür)} .
Kuruluşunuzda hangi üçüncü taraf kütüphanelerinin kullanıldığı konusunda daha fazla kontrol veya farkındalık sağlar.

Kaçırdığım satış noktaları var mı? İyileştirme metrikleri veren herhangi bir çalışma veya makale var mı?

dependency-management

— C. Ross
kaynak

Bence sen çivilenmişsin.

— Mike Partridge

Bozuk Maven kurulumlarında hayatımın saatlerini boşa harcamam. İyi niyetlerden bağımsız olarak, büyük bir cesette, sonunda içi boş bir kabuk oluncaya kadar hayatı emen, bakımsız bir karmaşa olacağına ikna oldum.

— MrFox

@suslik "Kırık Maven" kurulumunun ne olduğuna dikkat çekmek ister misiniz?

— Andrew T Finnell

@AndrewFinnell Diyelim ki derlemenizin derlenmesi için çekmeniz gereken projeler üzerinde çalışan 5 grup var ve zayıf koordinasyon nedeniyle herkes kütüphanelerin farklı sürümlerine bağlı olarak sona eriyor. Daha sonra, projelerden birinin henüz 'serbest bırakılması' amaçlanmadığı ortaya çıktı, ancak (hiç kimse maven'e söylemedi!) Tatmin etmeniz gereken bir bağımlılığınız var. Bunun 'gerçekleşmesi' gerekmiyor, ancak otomatik çözünürlük bunu çok kolay hale getiriyor. Eğer herkes svn'de korumak için bir / libs yönergesine sahip olsaydı, insanlar işler bitmeden önce durmaya ve soru sormaya zorlardı.

— MrFox

@MrFox Bu aslında Maven bağımlılığı çözümlemesi değil, zayıf koordinasyondan kaynaklanıyor. Aynı durumları yaşadıysanız ve ben Maven bir hayranı değilim, ama ben, araçlar prematüre bültenleri gibi insan-ilişkili sorunları çözmek gerekiyordu düşünüyorum test, kötü bakım, vb eksikliği, iletişim eksikliği

— Scriptin

Yanıtlar:

Olumlu sonuçlardan% 100 emin değilim. İşte birkaç olumsuzluk

Sıklıkla 3. taraf sunuculara / kararlı olmayabilecek uç noktalara bağımlılıklar eklersiniz.

Ben bower ile bazı bağımlılıkların repo silindi veya taşındı oldu. Böylece yeni bir geliştirici gelir, repo'yu klonlar, bower installerişilemeyen depolar için türler ve hatalar alır. Bunun yerine repo benim üçüncü taraf kodu kontrol olsaydı bu sorun kaybolur.

Bu, OP'nin çalıştırdığınız bir sunucuda tutulan kopyalardan borç çekip çekmediğinizi önerdiği gibi çözülür.
Noobs için daha zor.

Çok az komut satırı deneyimi olan sanat öğrencileri ile çalışıyorum. İşleme, arduino, Unity3D ile sanat yaparlar ve çok az teknik bilgi ile uğraşırlar. Yazdığım HTML5 / JavaScript'i kullanmak istediler. Bower yüzünden adımlar
1. Github'dan repo Zip'i indirin (github'daki her repo'nun sağında olduğuna dikkat edin. Çünkü git bilmiyorlar)
2. Düğümü indirin ve yükleyin (bower'ı yüklemek için npm'yi çalıştırabiliriz)
3. Git veya msysgit'i yükleyin (çünkü bower gerektirir ve birçok öğrencinin makinesine yüklenmez)
4. Bower'ı yükle ( npm install -g bower)
5. bower install (sonunda bağımlılıklarımızı elde etmek için)
Eğer dosyaları github depomuza iade edersek 2-5. Adımların tümü silinebilir. Bu adımlar muhtemelen size ve bana çok kolay geliyor. Öğrencilere çok kafa karıştırıcı edildi ve ne tüm adımları nerede ve ne kendisi için olduğunu bilmek istiyordu olabilir belki iyi öğrenmeyi olabilir ama sınıf konuya tamamen dik ve böylece muhtemelen çabuk unutulur.
Çekerken başka bir adım ekler.

Birçok kez yaptım git pull origin masterve kodumu test ettim ve bower install en son bölümleri almak için yazmam gerektiğini hatırlamak 5 ila 10 dakika sürüyor. Eminim bu bazı çekme komut dosyası kanca ile kolayca çözüldü.
Git dallanmasını zorlaştırır

2 dalın farklı bölümleri varsa, vidalısınız. Sanırım bower installher şeyden sonra yazabilirsiniz git checkout. Hız için çok fazla.

Olumlularınıza gelince, bunların her birine karşı örnekler olduğunu düşünüyorum.

Paylaşılan modüllerin, özellikle sürüm yükseltmelerinin dağıtılması ve içe aktarılması işlemini kolaylaştırır.

vs ne? Dağıtmak kesinlikle daha kolay değil. 20 yerine bir repo çekmek daha kolay değildir ve başarısız olma olasılığı daha yüksektir. Yukarıdaki # 1 'e bakınız

Paylaşılan modülleri kaynak denetiminden, hızlandırmadan ve çıkışları / check-in'leri basitleştirmeden kaldırır (20+ kitaplık içeren uygulamalarınız olduğunda bu gerçek bir faktördür).

Tersine, düzeltmeler için başkalarına bağımlı olduğunuz anlamına gelir. Eğer depsleriniz 3. taraf bir kaynaktan çekiliyorsa ve bir hata düzeltmeniz gerekiyorsa, yamanızın uygulanmasını beklemeniz gerekir. Daha da kötüsü, muhtemelen istediğiniz sürümü ve yamanızı ekleyemezsiniz, projenizle geriye dönük olarak uyumlu olmayan en son sürümü almanız gerekir.

Depolarını ayrı ayrı klonlayarak çözebilir ve ardından proje borçlarınızı kopyalarınıza yönlendirebilirsiniz. Ardından kopyalarınıza düzeltmeler uygularsınız. Elbette, kaynağı sadece repoma kopyalarsanız da yapabilirsiniz.

Kuruluşunuzda hangi üçüncü taraf kütüphanelerinin kullanıldığı konusunda daha fazla kontrol veya farkındalık sağlar.

Bu tartışmalı görünüyor. Geliştiricilerin 3. taraf kitaplıklarını kendi klasörlerine koymaları yeterlidir <ProjectRoot>/3rdparty/<nameOfDep>. Üçüncü taraf kütüphanelerinin ne kullanıldığını görmek de kolaydır.

Olumlu olmadığını söylemiyorum. Bulunduğum son takımda 100'den fazla 3. parti bölümü vardı. Sadece güllerin olmadığını belirtiyorum. İhtiyaçlarım için kamçıdan kurtulmam gerekip gerekmediğini değerlendiriyorum.

— gman
kaynak

Vay, çok olumsuz oylar ve onlar için tek bir gerekçe değil. Aferin! :(

— gman

Hiç bower kullanmadım, ancak installher ödeme yaptığınızda ihtiyaç bir tasarım hatası gibi görünüyor. Bir proje oluşturduğunda yapılandırmasını kontrol etmelidir: değişiklikler varsa, sıfırdan yeniden inşa etmelidir. Ayrıca, hareketli depolar Maven ile ilgisizdir, çünkü eserleri kodlu gerçek depoları değil, depolayan Maven deposundan çeker. Eserinizi ancak Maven deposunda yayınlarsanız değiştirebilir artifactIdve groupIdsonraki sürümünde değiştirebilirsiniz . Bu nedenle, # 1 ve # 4 puanlarınız özellikle Maven'le çoğunlukla alakasız. # 3 mvn clean(bazen) ile değiştirilebilir

— scriptin

Doğru olsa da, # 2 bir dezavantaj değil - bir değiş tokuş. Tabii ki, araçlarınızı öğrenmek zorundasınız! Örneğin, Git'i kavramak oldukça zor, ama dem noobs yüzünden bundan vazgeçmeyeceğim.

— scriptin

Oniki Faktör Uygulamasına bir göz atın

Özellikle bağımlılıklar hakkında söylediklerini okuyun . İyi tasarımın bağımlılıkları bulmak için bildirici bir mekanizma sağladığını fark edeceksiniz, Java'da bu genellikle Maven aracılığıyla gerçekleştirilir. Ivy ve NuGet iyi çalışıyor, ancak Maven şu anda bu alanda lider ve Ivy kesinlikle çok çalışıyor.

Maven serbest bırakma sürecine bağlı kalırsanız (resmi bir sürüm hazır olana kadar anlık görüntüler geliştirin, asla önceki bir sürümün üzerine yazmayı denemeyin, Nexus veya Artifactory gibi uygun bir havuz yöneticisi kullanın) o zaman güzelce aşağılayan bir oluşturma sürecine sahip olmalısınız.

Bir kez sağlam bir bildirim oluşturma süreciniz olduğunda, Jenkins ile Sürekli Entegrasyon , Sonar ile Sürekli Kod Analizi gibi diğer iyi uygulamalara kapı açar ve git'i kullanarak daha iyi bir sürüm kontrolü dallanma stratejisi arıyorsunuz .

Yukarıdakilerin her biri Maven olan çekirdeğe dayanır. Bugünlerde hemen hemen beyinsiz bir karardır.

— Gary Rowe
kaynak

Oniki Faktör Uygulamasına baktım, ama son derece çekişmeli ve sadece birazcık alakalı. Ayrıca Maven'i zorlamak neden bağımlılık enjeksiyonuna ihtiyacımız olduğunu açıklamama yardımcı olmaz. Genel olarak bu cevap Bağımlılık Enjeksiyonu satmama yardımcı olmuyor, sadece yapım sürecim için yapmam gereken çok şey anlatıyor.

— C. Ross

Bağımlılık Enjeksiyonu (tasarım deseni) Bağımlılık Yönetimi (oluşturma deseni) değildir. Sorunuzdaki en önemli hususları zaten ele aldınız. Ekibinizin bunları duyduktan sonra hala ikna etmeye ihtiyacı varsa, Bağımlılık Yönetiminin neye yol açacağını görmek nihai ikna edici olmalıdır.

— Gary Rowe

Ve ilk 10 listemizdeki # 1 öğe ...

(davul rulosu)

Her geliştirici, tüm bağımlılıkların tam olarak aynı sürümleriyle oluşturulur, bu nedenle üretime ne dağıtacağınızı merak etmek zorunda kalmazsınız.

— Ross Patterson
kaynak

Bunun bağımlılıkları kontrol etmekten farkı nedir? Aslında bağımlılıkları kontrol etmezseniz bazı üçüncü tarafların dağıtımınızı bozma riskini taşırsınız. Bazı bower dep biri silinmiş veya yeniden adlandırılmış bir repo işaret nerede birden fazla kez bu oldu. Kaynağı depomuza yeni kopyalamış olsaydım bu sorun ortadan kalkar.

— gman