Kaynak kontrolündeki ikili dosyalar

Gömülü cihazlar ve diğer garip dünyalar için geliştirirken, derleme işleminizin çok özel versiyonlarını kullanarak çok sayıda özel ikili dosya içermesi olasıdır. Yani soru şu ki, onlar kaynak kontrolünüzün bir parçası mı? Ofislerim "kaynak denetiminden çıkmak, kodu derlemek için ihtiyacınız olan her şeyi içerir" kuralına uyuyor ve bu da bazı ciddi tartışmalara yol açtı.

Buna karşı gördüğüm başlıca argümanlar kaynak kontrolü DB'yi, farklı ikili dosyaların bulunmayışını şişiriyor ( konuyla ilgili önceki sorulara bakınız) . Bu, önceki geliştiricinin amaçladığı kesin çevreye sahip olduğunuzu ve uygun dosyaları aramadan (belirli sürümleri az olmadan!) Kontrol etme, oluşturma, tanıma yeteneğine karşıdır.

VERSION CONTROL (yanlış isim: kaynak kontrol) düşüncesi, geçmişe geri dönmenize, değişikliklerin etkisini geri kazanmanıza, değişiklikleri görmenize ve neden yapılmasına izin vermektir. Bu, bazıları ikili şeylere ihtiyaç duyan, bazıları gerektirmeyen bir dizi gereksinimdir.

Örnek: Gömülü ürün yazılımı çalışması için normal olarak eksiksiz bir alet zincirine sahip olacaksınız: ya çok paraya mal olan özel bir derleyici ya da gcc'nin bir sürümü. Sevkiyatın yürütülebilmesi için alet zincirine ve kaynağa ihtiyacınız vardır.

Araç zincirlerinin versiyon kontrolünde kontrol edilmesi bir acıdır, fark yaratabilecekleri korkunç (eğer de olsa), fakat alternatif yok. Alet zincirinin ne olduğunu anlamak için 5 yıl içinde kodunuza bakmak isteyen adam için korunmasını istiyorsanız, başka seçeneğiniz yok: Alet zincirini de versiyon kontrolü altında bulundurmanız GEREKİR.

Yıllar boyunca bunu yapmanın en basit yönteminin kurulum CD'sinin ZIP veya ISO görüntüsünü oluşturmak ve bunu kontrol etmek olduğunu buldum. Giriş yapma yorumunun, takım zincirinin belirli üreticilerinin sürüm numarası olması gerekiyor. Gcc veya benzeri ise, kullandığınız her şeyi büyük bir ZIP içine toplayın ve aynısını yapın.

Yaptığım en uç durum, "toolchain" in (o zamanlar) SQL Server ve yüzlerce ve yüzlerce yama dosyasıyla birlikte bir dizi yapılandırma dosyası içeren çalışan bir Windows XP VM'si olduğu Windows XP Embedded. Bütün partiyi kurmak ve güncel tutmak yaklaşık 2-3 gün sürdü. Bunu korumak, gelecek nesil için ENTIRE VM'yi sürüm kontrolünde kontrol etmek anlamına geliyordu. Sanal diskin yaklaşık 6 x 2GB görüntüden oluştuğunu görünce, aslında oldukça iyi geçti. Üstünden geliyor ama benden sonra gelen ve kullanması gereken kişi için hayatı çok kolaylaştırdı - 5 yıl sonra.

Özet: Sürüm kontrolü bir araçtır. Etkili olmak için kullanın, kelimelerin anlamı gibi şeylere dokunmayın ve bundan "kaynak kontrolü" deyin, çünkü bundan daha büyük.

Neal Ford savunuyor Üretken Programcı bunu gerektiğini kaynak denetiminde ikilileri tutmak:

Neden ikili dosya tutulur? Günümüzde projeler, dış araç ve kütüphanelerden oluşan bir alana bağlıdır. Diyelim ki popüler günlük kayıt çerçevelerinden birini kullanıyorsunuz (Log4J veya Log4Net gibi). Bu günlük kitaplığı için ikili dosyaları derleme işleminizin bir parçası olarak oluşturmazsanız, onu sürüm denetiminde tutmalısınız. Bu, söz konusu çerçeve veya kitaplığın kaybolması durumunda bile yazılımınızı oluşturmaya devam etmenizi sağlar (veya daha büyük olasılıkla yeni bir sürümde bir değişiklik getirmektedir). Yazılımınızı sürüm kontrolünde oluşturmak için her zaman gerekli tüm evreni tutun(işletim sistemini eksi ve hatta sanallaştırma ile mümkün olsa bile; bu bölümün ilerleyen kısımlarında "Sanallaştırmayı Kullanma" konusuna bakın). Tutma ikili dosyalarını hem sürüm kontrolünde hem de paylaşılan bir ağ sürücüsünde tutarak en iyi duruma getirebilirsiniz. Bu sayede saat başı onlarla uğraşmak zorunda kalmazsınız, ancak bir yıl sonra bir şeyi yeniden inşa etmeniz gerekebilir diye kurtarılırlar. Bir şeyi yeniden inşa etmeniz gerekip gerekmediğini asla bilemezsiniz. İşe yarayana kadar inşa edersin, sonra unut gitsin. İki yıl öncesinden bir şeyi yeniden inşa etmeniz gerektiğini ve tüm parçalara sahip olmadığınızın farkına varmak paniğe neden oluyor.

Daha fazla katılamadım; Bu tartışmasız olarak VCS'yi tasarlamadığı bir görev için (ikilileri tutmak) altüst ederken, faydaların potansiyel dezavantajlardan ağır basacağını düşünüyorum. Ancak, yazarın daha sonra not ettiği gibi, bazen ikili dosyaları VCS'de tutmak pratik bir çözüm olmayabilir, bu yüzden başka seçenekler de düşünülmelidir - onları haritalanmış bir ağ sürücüsünde tutmak gibi.

İkili dosyalar çok büyük değilse, kesinlikle onları VCS'de tutardım. Bu durum sizin durumunuzda daha doğru görünüyor, çünkü ikili dosyalar muhtemelen küçüktür ve çok özel versiyonlarla çalışıyorsunuz. Ayrıca, çeşitli nedenlerden dolayı da bulmak zor olabilir (yazarlar web sitelerini kapattılar veya ihtiyacınız olan sürüm artık indirmek için listelenmiyor). Düşük olmasına rağmen, birkaç yıl içinde ne olacağını asla bilemezsiniz.

Keşke bu kitabı birkaç yıl önce, bir grafik kütüphanesini kullanarak bir oyun üzerinde çalışırken (ki bu dll dosyasıydı) okudum; Gelişimi bir süreliğine kesintiye uğrattım ve devam etmek istediğimde proje dll olduğu için dll'yi tekrar bulamadım.

Prensip olarak, “kaynak kontrolüne dahil etmek için ihtiyacınız olan her şeyi kontrol et” kampını takdir ediyorum, ancak bağımlılık yönetimi son birkaç yılda Maven, Ivy ve NuGet gibi araçlarla biraz gelişti.

Ayrıca, pratikte, bazı hoş olmayan yan etkiler yaratmak için ikili dosyaları kontrol etmekte buluyorum. Git / Mercurial, örneğin gerçekten ayarlanmamış, ve Subversion and Performance, ikili dosyalar içeren dalları birleştirirken sizi deliğe sokabilir.

Bağımlılık yönetimi çözümü ile, kaynak kontrollü bir dosyada projenizde hangi paket adlarını ve projenizin hangi versiyonlara bağlı olduğunu belirlersiniz. Neredeyse tüm bağımlılık yönetimi araçları, bir çeşit versiyonlama ve adlandırma kuralını izleyerek bağımlılıklarınız için özel bir depo oluşturmanıza izin verir; Bir derleme yaptığınızda, bağımlılık yönetimi aracı tüm açık kaynak ve mülk bağımlılıklarınızı onaylanmış bir kaynak listesinden çözecek ve daha sonra bunları yerel önbelleğinize yerleştirecektir. Bir dahaki sefere aynı sürüm bağımlılıklarıyla kurduğunuzda her şey zaten var ve çok daha hızlı gidiyor.

Özel havuzunuz daha sonra geleneksel dosya sistemi yedekleme araçlarıyla yedeklenebilir.

Bu, kaynak ağaçtan bir ton ikili dosya çekildiğinde karşılaştığım yavaşlamaları önler ve havuzunuzun çok fazla zorlu dosyalara sahip olmasını önler. Belirli bir bağımlılık için ad ve sürüm numarasına göre yalnızca bir konum vardır, bu nedenle başa çıkmak için bir birleştirme çatışması yoktur ve yerel dosya sistemi önbelleğe alma, yerel kopyanızın ne zaman değiştiğini değiştirme maliyetini değerlendirmek zorunda kalmayacağınız anlamına gelir. güncellemeleri alıyorsun.

Kaynak kontrolü kaynaklar içindir. Kaynaklar, başka şeylerden yapamadığınız şeylerdir. Kaynak olarak nitelendirilen bazı dosyalar ikili olabilir.

VCS'mde çok sayıda ikili dosya var, ancak her biri yazmadığım ve bakımını yapmadığım bir üründen çıkma birimi. Bu, sıkıştırılmış bir tarball olarak bırakılan GNU ccRTP gibi bir şey olabilir. Bu tarball benim kaynağım ve tek bir otomatik adımda bitmiş bir ürüne (benim için bir Makefile ve bir RPM özelliği) dönüştürmek için ihtiyaç duyduğum altyapı ile birlikte kontrol ediliyor. CcRTP'nin yeni bir sürümü olduğunda, yeni tarball'a değiştirilmiş kaynak olarak davranıyorum: kullanıma alınmış bir kopyaya giriyor, kuruluyor, test ediliyor ve VCS'ye geri verildi. Aynısını, kaynakla gönderilmeyen ticari ürünlerle (derleyiciler, kütüphaneler vb.) Yaptım ve aynı şekilde çalışıyor. Unpack-configure-compile-pack yerine, sadece unpack-pack. Her gece inşa eden yazılımmake ve bitmiş ürünler olsun.

Çoğu VCS, okunaklı bir kaynağın uğraşmasını kolaylaştıracak ve saklanacak daha verimli hale getiren özelliklere sahiptir, ancak ikili dosyalar için uygun olmadığını söyleyenler, eğer kullanılmadan ortaya çıkarsa, gerçekten doğru değildir. Bir VCS'nin ikili dosyalarla dahili olarak nasıl başa çıkacağı tamamen yazarlarının yalnızca farklılıkları saklamaya çalıştığını düşündüğünün çabaya değip değmeyeceğine bağlıdır. Şahsen, ccRTP dağıtımının tam kopyalarının 600K'da bir pop'unun saklanmasının, bir sürümünü diğer tüm kaynaklarımla birlikte etiketleyebilmekten daha fazla olduğunu düşünüyorum.

Bu bana bir süre önce Java'nın sahip olduğu "depolardaki kavanozlar" sorununu hatırlatıyor. Java uygulamaları geliştiren insanlar bağımlılıklarını (ikili jar dosyaları) depolara itmek için kullanıldı. Herkes bundan memnun kaldı, çünkü "tek tıkla" sisteminizi kurduk ve disk alanı ucuz, kimin umrunda. Sonra Maven geldi ve tüm bu ikili hırsızlıktan kurtulabiliyordunuz ve yalnızca yerel önbellek deposuyla hala mermi prof inşalarını sürdürüyorsunuz. Yine de "tek tıklamayla" yapı sisteminiz var, ancak kaynak denetiminin orada hiçbir anlamı olmayan ikili dosyaları karıştırması gerekmiyor.

Bu yüzden, evet, ikili dosyaları kaynak kontrolden çıkarabilirsiniz, fakat bu derleme yapmaları için derleme sistemini değiştirmenizi gerektirir. Özel bir yazılım olmadan (Maven gibi) bu onları çıkarmak için çok çaba olabilir.

Kaynak kontrolünüz kaynakları yaptığınız iş için tutar. Verilen bir ikili blob kaynaklardan yeniden oluşturulabilirse, bu bir kaynak değildir ve kaynak kod deposuna girmemelidir. Sadece kontrol edilemeyen bloklar kaynak kontrolünde bulunmalıdır.

Genellikle kaynakların süresi boyunca oluşturduğunuz ikili blobların başka bir depo ağ klasörünüz vardır. Bunlar müşterilere dağıtılabilir veya projelerde kullanılabilir (her şeyi sıfırdan inşa etmek yerine).

Öyleyse, eğer bir kaynaksa onu içine koy. Olmazsa yapma.

Amaç, en son kodu alabilmek ve herhangi bir şeyi kurmak / kurmak zorunda kalmadan oluşturmak.

Yaptığım birçok yerde, bu bağımlılık ikili dosyalarının kontrol edilmesi anlamına geliyor. Diğerlerinde bu, derleme komut dosyalarının bağımlılıkları otomatik olarak indirip aldıkları anlamına gelir.

Bkz bu blog yazısı konuyla ilgili Derek Greer tarafından.

İki farklı inşa aşaması olan bir projede çalışıyorum

• "ana program oluşturma", binlerce kaynak kod metin dosyasına kıyasla sadece birkaç ikili dosyaya ihtiyaç duyar, bu nedenle ikili dosyalar depoya kontrol edilir. Bu iyi çalışıyor.

• Yükleyici derlemesi birçok üçüncü parti bileşen gerektirir (bazıları Adobe Reader gibi yalnızca yükleme CD'sine kopyalanır). Bunları depoya yerleştirmiyoruz. Bunun yerine, bu bileşenler bir ağ sürücüsünde bulunur (eski sürümleri bile) ve derleme komut dosyaları bunları doğru yere kopyalar. Elbette, çoğaltılabilir yapılara sahip olmak için, üçüncü taraf bileşenlerinin depolandığı herhangi bir klasörü değiştirmemeye özen göstermek isteyen herkes.

Her iki strateji de gayet iyi çalışıyor ve "kodu kontrol etmek için ihtiyacınız olan her şeyi içerir; kodu derlemek için" şartını yerine getiriyor.

Gelecekte bir noktada ürünün belirli sürümlerini yeniden oluşturmak için ihtiyacınız olan her şeyi tutmanız gerekir.

Ancak her şeyi Kaynak Kontrolü'nde tutmak zorunda değilsiniz.

Bir şirket donmuş bir sunucu rafı tuttu (çünkü işletim sistemi yalnızca belirli bir donanıma ve araç zinciri yalnızca bu işletim sistemine dayanıyordu ve kaynak bu araç zincirine bağlıydı). Bunu Kaynak Kontrolü'nde kontrol edemiyorum.

Bir derleme için gereklilikleri ayırmanız gerekirse, iki sürüm kontrol sisteminin senkronize edilmesini sağlamanın muhasebe problemi vardır. örneğin bu dolaptaki donanım kutusu veya bu korunan yedekleme birimindeki VM veya ikili dosyalar, bu SVN Kaynak Kodu revizyonu, vb. ile devam eder.

Aklımda SCM için ikili giriş yapmak çok kaos. Üçüncü bölüm kütüphanelerine çok bağımlılığı olan çok karmaşık bir proje yürütmüştüm. Benimsediğimiz ilkeler:

1. Tüm kaynak kodları SCM ile yönetilir
2. Tüm bağımlılıklar büyük tutulma entegrasyonuna sahip Ivy ile yönetilir.

Bu oldukça iyi çalışıyor. Kaynak kodun derlenebileceği her harici kütüphanenin sürümü hakkında bir yapılandırma dosyasına sahibiz. Bu yapılandırma dosyası SCM'de kontrol edilir, bu nedenle kaynak kodu ilerledikçe gelişir. Bu yaklaşımı uygulayarak, dış kütüphanelerin sürümünü karıştırmadan bir yapıyı tam olarak çoğaltabiliriz.

Şahsen, felsefi olarak, kaynak denetiminin , dosya içeriğini değil, büyük ikili dosyalara (küçük ikili kaynaklar iyidir ) işaretçilerde denetlemesine izin vermeye meyilliyim . Bu işaretçi, ikili dosya içeriğinin bir karmasını içerir.

İkili dosyanın kendisi kaynak kontrolü tarafından yönetilemez. İşaretçi veya hash kullanılarak özel olarak alınabilecek bir tür kütüphanede saklanır.

Git LFS ve git eki bunu yapar, ancak ikili dosyaları bir dereceye kadar yönetmeye çalışırlar, bunu yapmalarını istemiyorum. Git'in yalnızca sağlama toplamlarını depolamasını ve ikili dosyalarımın değişip değişmediğini bana söylemesini istiyorum - ancak bunları yönetmeyi ve depolamayı denemeyi istemiyorum. Bunu kendim yapmak istiyorum.

Git'in küçük ve orta büyüklükteki ikili dosyaları işleyebileceğini düşünüyorum ama büyük ikili dosyaları yönetmek için doğru araç olduğundan emin değilim.