Yalnız bir proje yapıyorsanız - bir depodan oluşturmak için CI araçlarını kullanır mısınız? Hudson ve Cruise Control'ü bir ekip ortamında kullandım, burada herhangi bir şey kontrol eder etmez inşa etmek çok önemlidir.
Bence sürüm kontrolünün değeri hala açıktır, ancak her makineden sonra derlemem gerekir mi, sadece yerel makineme dayanacakmış gibi görüyorum ve başka hiç kimse işlemiyor mu?
Yanıtlar:
Bir projede sürekli bir entegrasyon aracı kullanmayı planlıyorum ve benzersiz geliştiriciyim. İhtiyaç geliyor çünkü
Platformlar arası ve ekip çalışması hazırlığı dışında ihtiyacı görmüyorum. Önemli olan bir çeşit kaynak kontrol yazılımına sahip olmak ve yedekleri tutmak için birkaç depoya sahip olmaktır. Bu, gerektiğinde etrafında araçlar oluşturmanıza yardımcı olacaktır.
Yapım zamanlaması hakkında Mercurial kullanıyorum ve ekip çalışması havuzu olmayan bir entegrasyon havuzu kuruyorum. Bu yüzden, entegrasyon sistemini kurmaya çalışma zamanı geldiğini hissedene kadar ekip çalışması deposundaki değişiklikleri zorlayın. Sonra ekip çalışması deposundan entegrasyon deposuna geçiyorum ve bu da yapıyı tetikleyecek. Daha sonra her gün bir kez entegrasyon deposundaki ekip çalışmasını çekecek bir senaryo da ekliyorum.
Burada, projemde neredeyse tüm gün çalıştığımı varsayıyorum, ancak bu her zaman doğru değil. Derlemelere ne sıklıkta ihtiyacınız olduğuna göre bir derleme zamanlaması ayarlamanız gerekir. Daha önce çalıştığım bir oyun şirketinde CruiseControle'u kullandık ve her saat tam bir bina inşa etti. Gerektiğinde istediğimiz zaman bir yapıyı zorlayabiliriz.
Bir ev projesi için, günde bir kez zaten "sık sık" olabilir. Temel gereksinim kullanıcının kolayca bir yapı kurmaya zorlamasına izin vermek olacaktır.
Kısa bir tefekkürden sonra, solo bir geliştirici için bir takımdan daha önemli olabileceğini öneririm .
En temel düzeyde bir CI sunucusu, uygulamanızı kararlı bir kaynaktan sıfırdan oluşturabileceğinizi gösterir - iyi bir test seti ile birlikte sıfırdan oluşturup çalıştırabileceğinizi göstermelidir.
Yapmaya çalıştığım şeylerden biri, derlememin konuşlandırılabilir bir paket içermesini sağlamak olduğundan, dağıtmak için bir şeyler alabileceğinizi de biliyorsunuz (temiz ve bilinen bir durumdan / sürümden).
Aslında, şimdi Dosya | Yeni Proje yaptığınızda muhtemelen havuzunuzu oluşturmayı veya eklemeyi ve CI derleme betiği ve dağıtım kurulumunuzu kurmayı da içermelisiniz (bu yalnızca xcopy dağıtımı için bir yığın dosyayı sıkıştırmak için bile olsa)
Zeyilname (2016) - günümüzde CI sistemim de dağıtım sürecimin ayrılmaz bir parçası olacak, bu yüzden değeri arttı ve kesinlikle onsuz teslim edilebilir bir proje yürütmeyeceğim. Otomatik basma düğmesi dağıtımı, işlemden çok fazla stres alır ve bir şekilde bir yapı sunucusunu şekillendirir veya oluşturur, bunun ayrılmaz bir parçasıdır.
Taahhüt eden tek kişi olduğumda, gerçekte taahhütte bulunmadan önce sadece inşa edip test ediyorum . Genellikle aşağıdaki gibi bir makefile hedefi kullanın:
make sense
Bu, tüm testleri yapılandırır, oluşturur, çalıştırır (valgrind farkında), lints çalıştırır, vb. Bildiğim kadarıyla tek iteceğim, Hudson gibi bir şeyin gücüne gerçekten ihtiyacım yok.
Ek olarak, ana depoyu besleyen birkaç şubeniz olan bir ortamda, herkes taahhütte bulunmadan veya itmeden önce her zaman çekmeyi takip ederse, CI sunucusu biraz fazla öldürme olabilir. Son derleme kırdı ne yazarın Cuma günü pizza satın iyi bir kural genellikle işler çok sorunsuz çalışır tutar :)
Bir projenin açıkça kendi liderleri olan alt sistemlere ayrıldığı bir duruma girerse, gerçekten Hudson gibi bir şey kullanmayı düşünmelisiniz. Birisi yerel olarak test edebilir, başka bir alt sistemle yarışı kaybedebilir ve sonunda toksik bir şey itebilir.
Ayrıca, hızlı hareket eden bir projenin çatalını (örneğin, Linux çekirdeğine yönelik kendi yama kümenizi) koruyorsanız, o projede 'solo' olsanız bile, Hudson gibi bir şey kullanmayı düşünmelisiniz. Bu, özellikle doğrudan ana hattan şubeye / temel almaya başladığınız zaman geçerlidir.
make: don't know how to make sense. Stop. Ahh!
Bunun sadece güzel bir bonus olduğunu söyleyemem, orada yalnız sanatçılar için yüksek kaliteli yazılım mühendisliği için hayati olduğunu söyleyebilirim. Çoğumuz, daha sonra düzeltmek için yeterince kolay olduğunu düşünüyorlarsa, kalite standartlarının biraz kaymasına izin vereceğiz. Yazılımı bu durumda yürütürseniz, esasen kaynak kontrolünüzde değersiz bir kod tabanına sahip olursunuz.
Eğer uygun şekilde yapıştırılırsa (yani, testleri atlamazsınız ve her taahhütte bulunduğunuzdan emin olursunuz) CI sizi yine de taahhüt edeceğinizden daha yüksek bir kalite standardına uymaya zorlar.
Her şeyin yolunda gidip gitmediğini görmek için bekleme sürenizi kısaltmak istiyorsanız önemlidir. Kaydettiğiniz anda IDE'nizi sizin için bir şeyler derlemesine rağmen, otomatik olarak birim testleri çalıştırmaz, bu nedenle CI sunucumun birim testlerini çalıştırmasını ve kod kapsamı raporlarını ve kodumun diğer kalite analizini en kısa sürede çalıştırmasını istiyorum Ben itiyorum.
Yapmam gereken tek tetikleyici güncellemelerimi sürüm kontrolüne aktarmak ve kodlamaya geri dönebilirim. Kodlamayı düşünürken, CI sistemi, beynim bir sükunete girdiğinde arada bir bakacağım uzun soluklu kalite raporlarını yapmakla meşgul.
Ben itmek kod için yapıları yapar aynı dizüstü bilgisayarda ayrı bir VMWare makine var. Bunu yapmak için sadece bir anahtar teslimi Linux VMWare görüntü almak ve apt-get kullanarak jenkins yüklemek ve birkaç küçük yapılandırma değişiklikleri yapmak.