Zor kazanılmış deneyim bana hemen hemen her şeyin kaynak kontrolünde olduğunu öğretti . (Buradaki yorumlarım, patentli donanım üzerindeki gömülü / telekom sistemleri için özel ve bazen de bulmak zor araçlarla geliştirilen on yıl ve bir buçuk renkle renkli.)
Buradaki cevapların bazıları "ikili dosyaları kaynak kontrolüne alma" diyor. Bu yanlış. Çok sayıda üçüncü taraf koduna ve satıcılardan çok sayıda ikili kitaplığa sahip bir ürün üzerinde çalışırken, ikili kitaplıklara göz atın . Çünkü, yapmazsanız, o zaman bir noktada yükseltme yapacaksınız ve başınız belaya girecek: derleme kırılıyor çünkü derleme makinesi en son sürüme sahip değil; Birisi yeni adama eski CD'lerin kurulumunu yapar; wiki projesi, hangi versiyonun kurulacağı konusunda eski talimatlara sahiptir; Eğer satıcı ile yakın çalışma varsa vb Daha da kötüsü, belirli bir sorunu çözmek ve bir hafta içinde size kütüphanelerin beş takım göndermek için, sen gerekirHangi ikilik kümesinin hangi davranışı sergilediğini izleyebilme. Kaynak kontrol sistemi tam olarak bu sorunu çözen bir araçtır.
Buradaki cevapların bazıları "alet zincirini kaynak kontrolüne alma" diyor. Bunun yanlış olduğunu söylemeyeceğim, ancak bunun için sağlam bir konfigürasyon yönetimi (CM) sistemi yoksa , takım zincirini kaynak kontrolüne koymak en iyisidir . Yine, yükseltme sorununu yukarıda belirtildiği gibi düşünün. Daha da kötüsü, işe alındığımda etrafta dolanan alet zincirinin dört ayrı tadının olduğu bir proje üzerinde çalıştım - hepsi aktif kullanımda ! Yaptığım ilk şeylerden biri (çalışacak bir yapı elde etmeyi başardıktan sonra) takım zincirini kaynak kontrolü altına aldı. (Sağlam bir CM sistemi fikri umudun ötesindeydi.)
Ve farklı projeler farklı araç zincirleri gerektirdiğinde ne olur? Örnek olay: Birkaç yıl sonra, projelerden biri bir satıcıdan yükseltme aldı ve tüm Makefiles'ler kırıldı. GNU markasının daha yeni bir versiyonuna güvendikleri ortaya çıktı. Böylece hepimiz yükselttik. Vurmaca, başka bir projenin Makefiles'leri kırıldı Ders: GNU markasının her iki versiyonunu da uygulayın ve proje ödemenizle birlikte gelen versiyonu çalıştırın.
Veya, her şeyin çılgınca kontrolden çıktığı bir yerde çalışıyorsanız, "Hey, yeni adam bugün başlıyor, derleyicinin CD'si nerede?" "Dunno, Jack'in bıraktıklarından beri onları görmedim, o CD'lerin koruyucusuydu." “Ah, bu 2. kattan çıkmadan önce olmadı mı?” "Belki de bir kutu içindedirler." Araçlar üç yaşında olduğundan, bu eski CD'yi satıcıdan alma ümidi yoktur.
Derleme komut dosyalarınızın tümü kaynak kontrolüne aittir. Herşey! Çevre değişkenlerine kadar. Yapma makineniz, projenin kökünde tek bir komut dosyası çalıştırarak projelerinizden herhangi birini yapabilecek durumda olmalıdır. ( ./buildmakul bir standarttır; ./configure; makeneredeyse kadar iyidir.) Komut ortamı, ortamı gerektiği gibi ayarlamalı ve daha sonra ürünü oluşturan herhangi bir aracı (make, ant, vb.) başlatmalıdır.
Çok fazla iş olduğunu düşünüyorsanız, değil. Aslında bir ton iş tasarrufu sağlar. Dosyaları, bir kez başında ve sonra ne zaman yükseltme yaptığınıza bağlıyorsunuz. Hiçbir yalnız kurt kendi makinesini yükseltemez ve bazı araçların en son sürümlerine bağlı olarak bir takım kaynak kodunu işleyemez, bu da herkes için yapıyı bozar. Yeni geliştiriciler kiraladığınızda, onlara projeyi kontrol etmelerini ve çalıştırmalarını söyleyebilirsiniz ./build. 1.8 sürümü çok fazla performans ayarına sahipse ve kod, derleyici bayrakları ve ortam değişkenlerini ayarladıysanız, yeni derleyici bayraklarının yanlışlıkla kod 1.7 sürümüne uygulanmadığından emin olmak istersiniz, çünkü gerçekten de koda ihtiyaç duyarlar onlarla birlikte devam eden değişiklikleri veya bazı kıllı yarış koşullarını görürsünüz.
En iyisi, bir gün kıçınızı koruyacak: Ürününüzün 3.0.2 sürümünü bir Pazartesi günü gönderdiğinizi hayal edin. Yaşasın, kutla. Salı sabahı, bir VIP müşterisi, destek hattını arayarak, 18 ay önce gönderdiğiniz 2.2.6 sürümündeki bu kritik, acil hatadan şikayetçi . Ve hala sözleşmeye bağlı olarak desteklemelisiniz ve hatanın yeni kodda sabitlendiğinden emin oluncaya kadar yükseltme yapmayı reddediyorlar ve dans etmenizi sağlayacak kadar büyükler. İki paralel evren var:
Kaynak kontrolünde kitaplıkların, araç zincirinin ve komut dosyalarının olmadığı ve sağlam bir CM sisteminizin olmadığı evrende ... Kodun doğru sürümünü kontrol edebilirsiniz, ancak oluşturmaya çalıştığınızda her türlü hata size olur. Bakalım, Mayıs ayında araçları yükselttik mi? Hayır, o kütüphanelerdi. Tamam, eski kütüphanelere geri dön - bekle, iki yükseltme oldu mu? Ah evet, bu biraz daha iyi görünüyor. Ama şimdi bu garip linker kazasında tanıdık geliyor. Oh, çünkü eski kütüphaneler yeni araç zinciriyle çalışmadı, bu yüzden yükseltmek zorunda kaldık, değil mi? (Eforun geri kalanının acısını size bırakacağım. İki hafta sürüyor ve sonunda kimse mutlu değil, siz değil, yönetim değil, müşteri değil.)
Her şeyin kaynak kontrolünde olduğu evrende, 2.2.6 etiketini inceleyin, bir saat içinde bir hata ayıklama hazırlayın, bir veya iki gününü "VIP hatalarını" yeniden oluşturmak, nedenini bulmak, düzeltmek Mevcut sürüm ve müşteriyi yükseltmeye ikna etmek. Stresli, ancak saç çizginizin 3 cm yüksek olduğu diğer evren kadar kötü değil.
Bununla birlikte, çok ileri gidebilirsin:
- Bir "altın kopyasına" sahip olduğunuz standart bir işletim sistemi kurulumuna sahip olmalısınız. Muhtemelen bir README, bunu belgelemek olduğunu gelecek nesillere o sürümü 2.2.6 biliyoruz ve önceki yalnızca RHEL 5.3 ve 2.3.0 üzerine kurulmuş ve daha sonra sadece Ubuntu 11.04 üzerine inşa böylece kaynak denetiminde. Takım zincirini bu şekilde yönetmeniz daha kolaysa, bunun için gidin, güvenilir bir sistem olduğundan emin olun.
- Proje dokümantasyonu kaynak kontrol sisteminde saklamak zahmetlidir. Proje belgeleri her zaman kodun önündedir ve geçerli sürüm için kod üzerinde çalışırken bir sonraki sürümün dokümantasyonu üzerinde çalışmak nadir değildir. Özellikle, tüm proje belgeleriniz, farklılaştıramayacağınız veya birleştiremeyeceğiniz ikili belgelerse.
- Derlemede kullanılan her şeyin sürümlerini kontrol eden bir sisteminiz varsa kullanın ! Sadece tüm ekipte senkronize etmenin kolay olduğundan emin olun, böylece herkes (inşaat makinesi dahil) aynı araç setinden çeker. (Debian'ın geliştiricisi ve python's virtualenv'in sorumlu kullanımı gibi sistemleri düşünüyorum.)