Bağımsız değişkenler, ikili dosyaları SCM'lere iade etmeyi yineliyor


10

Öncelikle Java uygulamaları oluşturan bir şirket için çalışıyorum ve herkesi SCM'ye ikili dosyaları (bağımlılıklar ve son ürünler) iade etmeyi durdurmaya ikna etmeye çalışıyorum.

Bunun kötü bir uygulama olduğunu biliyorlar, ancak "işe yaradığını" düşünüyorlar ve birçok insan Maven'i ve Ant'in yanı sıra diğer inşaat araçlarını bildiğinde bile bu gerçekten bir sorun değil. Hem PM'ler hem de programcılar (yaklaşık 50 kişi) karşı herhangi bir argümanı dinlemeye ve hatta yedek alan kaybı olduğunu kabul etmeye hazırlar, ancak alışkanlık değişikliği çok çaba gerektireceği için gerçekten ikna etmek istiyorum. Bir değişikliği desteklemek için hangi argümanları kullanıyorsunuz?

Düzenleme: Tamam, bağımlılıklar ve oluşturulan dosyalar gibi neredeyse değişmeyen dosyalar arasında bir ayrım yapmak mantıklı. Yine de, ikincisine karşı nedenlerle ilgileniyorum.

Yanıtlar:


7

Depolama alanı ucuzdur ve bu yüzden dosyaları neden kontrol etmeniz veya etmemeniz gerektiği konusunda ikna edici bir argüman değildir.

Bunun yerine, SCM'nin amacına itiraz edebilirsiniz. SCM tarafından izlenen her dosya, ekibinizin yaptığı paralel, dağıtılmış değişiklikleri yönetme ihtiyacını temsil eder. İki ekip üyesi aynı dosyayı değiştirmeye çalışana kadar bunların hiçbiri belirgin değildir. Bu değişiklikleri çözmek, SCM'nin gerçekte ne olduğudur, başka bir geliştiricinin çalışmasının yanlışlıkla üzerine yazılmasını önler ve umarım bu değişiklikleri birleştirme sürecini otomatikleştirir.

İkili dosyaları birleştirmek genellikle gerçek bir zorluktur, çünkü genel bir birleştirme aracının birleştirilmiş ikili dosyanın nasıl çalışması gerektiğini tahmin etmesinin akılcı bir yolu yoktur. Belirli bir dosya türünü tanımak için özel olarak tasarlanmadığı sürece, dosyadaki dizinlerin veya uzaklık işaretleyicilerinin nasıl çalıştığı hakkında yeterince bilgi sahibi olamaz.

Bu, ikili dosyayı el ile birleştirmenin ve ardından SCM'ye dosyanın bu kadar birleştirildiğini bildirmenin geliştiriciye bağlı olduğu anlamına gelir. Bunu yapmak bir geliştirici olduğundan, birleştirme, önceki check-in'lerin tüm değişikliklerini gerçekten kapsamıyor olabilir ve dosya ikili olduğundan, birleştirmeyi doğrulamanın otomatik bir yolu yoktur.

Sanat varlıkları gibi proje kaynaklarını gerçekten temsil eden ikili biçimler için bu talihsiz, ancak gerekli bir adımdır. Ancak derleme çıktıları kaynak değildir. Bunları birleştirmeye gerek yoktur, çünkü kaynaklar birleştirilebilir ve sonuçta ortaya çıkan bir yapı çıktısı yeniden oluşturulabilir. Bu değişiklikleri izlemek ve yönetmek% 100 israftır. Çok fazla olmasa da SCM'nin kaynaklarını boşa harcıyor, ancak geliştiricinin sahte birleştirme hatalarını aşmak için zaman harcıyor. Geliştirici zamanı çok pahalıdır ve onu boşa harcayan her şey bir kanserdir.

Öte yandan, yapı çıktılarının arşivlenmesi gereken özel bir durum vardır. Projenin daha önce gönderilmiş veya dağıtılmış herhangi bir versiyonu muhtemelen süresiz olarak saklanmalıdır. Bir müşterinin sorunları olduğu asıl yapının bayt kopyasının tam bir bayt kopyasına sahip olması, sahip olduğu tam sürüme sahip olacağınız için bu müşteriyi desteklemeyi çok daha kolay hale getirebilir.

Bu yedekleme muhtemelen kaynak kodu ile aynı havuzda olmamalıdır, çünkü bunlar genellikle farklı programları takip eder ve temelde farklı yapılara sahiptir.


10

Bağımlılıklar, ikili biçimde bile, başka biri projeyi aşağı çektiğinde işe yarayacak şekilde kontrol edilmelidir. Ana endişe, dosya türü değil, dosyanın nasıl oluşturulduğu. Kullandığım temel kural, başka bir dosya kullanılarak oluşturulabiliyorsa, teslim alınmamasıdır - bu, otomatik olarak oluşturulan belgeler, oluşturduğum ikili dosyalar vb. Anlamına gelir.


2

SCM'leri kullanmanın birincil avantajlarından biri, sisteminizi geçmişte istediğiniz zaman yeniden yapılandırabilmenizdir. Dolayısıyla, son yapınızı SCM'nizde saklamanın bir anlamı yoktur, çünkü sadece revizyon numarasını kontrol edebilir ve oluşturabilirsiniz.

Bağımlılıklardan bahsediyorsunuz ... SCM'niz yeni bir makineye temiz bir ödeme (dev ortamı ile) yapabilmeniz, derleme yapabilecek ve başka bir şey yüklemenize gerek kalmadan sisteminizi oluşturabilmeniz için ayarlanmalıdır. Dolayısıyla, ikili bağımlılıkları SCM'nizde tutmak iyi bir fikirdir. Kütüphaneler nadiren değişir, bu yüzden fazla yer kaplamazlar.

Neredeyse hiç kimse bunu yapmıyor.


Tamam, katılıyorum: bağımlılıklar nadiren değişir. Ancak bir satır kaynak kodu değiştirilmiş bir 20Mb WAR dosyası teslim edilmeyi hak etmiyor.
Aralık'taki Iter

3
Neden olmasın? Disk alanınız bitecek mi? Eğer kaynağınız yoksa ve gerekli bir bağımlılık varsa, o zaman başka seçeneğiniz yoktur, eğer yaparsanız, ikili olarak sayılmaz ve ihtiyacınız olduğunda inşa edebilirsiniz.
Henry

0

Hem kaynak hem de nesne dosyalarını içerecek şekilde gereksiz görünüyor (kaynak dosyalar açıkça gereklidir). Sadece gereksiz olmanın yanı sıra, nesne dosyaları çok fazla yer kaplayabilir. Firmanız dağıtılmış bir SCM (Git, Hg, Bzr) kullanıyorsa, bu ikili dosyalar kopyalanmalı ve tüm geliştiriciler arasında saklanmalıdır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.