Sürekli Entegrasyon: hangi frekans?

Her taahhütten sonra her zaman inşaatlar başlattım, ancak bu yeni projede, mimarlar benden sıklığı "15 dakikada bir inşa" olarak değiştirmemi istedi ve bunun neden iyi bir neden olduğunu anlayamıyorum " msgstr "her taahhüt üzerine bina".

Öncelikle, bazı ayrıntılar:

• Objective-C (iOS 5) projesi
• 10 geliştirici
• her yapı aslında ~ 1 dakika sürer ve yapı ve birim testi içerir.
• entegrasyon sunucusu bir Mac Mini, bu nedenle bilgi işlem gücü burada gerçekten sorun değil
  • Jenkins'i XCode eklentisiyle kullanıyoruz

Benim iddialarım, her bir taahhütte derlerseniz, şu anda neyin yanlış gittiğini görebilir ve diğer geliştiricileri çok sık rahatsız etmeden doğrudan hatalarınızı düzeltebilirsiniz. Ayrıca test cihazımız UT hatalarıyla daha az rahatsız oluyor. Argümanları, geliştiricilerin "derleme hatası" postaları ile sular altında kalacağı (bu tamamen doğru değil, çünkü Jenkins yalnızca ilk kırık derleme için bir posta gönderecek şekilde yapılandırılabilir) ve bu sıklık, yapıları çok yüksek.

Peki, bu konuda ne düşünüyorsun?

Hızlı başarısızlık iyi bir prensiptir - yapının ne kadar erken bozulduğunu bilirseniz, suç işleme taahhüdü o kadar çabuk tespit edilebilir ve yapı sabitlenir.

Her taahhüde dayanarak yapılacak doğru şeydir.

Projenin böyle bir süre içinde yüksek hacimli taahhütleri varsa 15 dakikada bir inşa etmek anlamsız olabilir - kötü taahhüdü izlemek daha uzun sürebilir ve belirlenmesi zor olabilir (biri birden fazla taahhüdün farklı şeylere sahip olduğu bir durumda da olabilir) inşa kırmak). Ayrıca sessiz zamanlarda (gece?) Hiç değişiklik yapılmamasına rağmen yeniden inşa etme olasılığınız da vardır.

Yapı bir sorun olacak kadar sık ​​kırılırsa, takımı yapıyı kırmamanın önemi ve bunun gerçekleşmemesini sağlayan teknikler hakkında sık sık eğitmek için cevap verin (sık sık getirmeler, check-in dansı, derleme ve çalıştırma birim testleri yerel vb ...).

Hiçbir şey değişmezse, her 15 dakikada bir yapı yapmanın anlamı yoktur. Ama aynı şekilde bir dezavantajı yok, afaik, jenkinler sadece başarısız ve sonra başarı üzerine e-posta gönderecek ve aradaki her şey değil (örneğin 10 başarısız).

Bunu her taahhütte yapıyoruz. Bununla birlikte, depoyu onbeş dakikada bir yoklayıp değişiklikleri kontrol ediyoruz, belki de meslektaşlarınızın bahsettiği şey budur.

10 geliştiricinizin her onbeş dakikada bir defadan fazla taahhütte olmasını mı bekliyorsunuz? Bu oldukça yüksek bir tahmin gibi geliyor. 10 dev's, her 150 dakikada bir aynı kişinin tekrar işlediği anlamına gelir, yani 2.5 saattir. Ortalama bir günde her geliştirici 3 defa işlem görür. Şahsen bir taahhütte bulunuyorum ~ 2 gün ... bazen daha bazen daha az.

Yalnızca 15 dakikada bir geliştiricilere daha fazla posta gönderir . Çünkü inşaatı kimin kırdığını kesin olarak bilmeyecek ve daha fazla kişiye posta gönderecek.

Metriklere gelince, bu gerçekten bir sorunsa - hangi metriklerle ilgili bir sorun olduğunu düşündüklerini bilmediğim için söyleyemem - metrikleri toplamak için her zaman başka bir iş yapabilirsiniz.

Belki de gereklilik " 15 dakikada en fazla bir kez inşa edilecek" olacaktır . Bu, çok sık taahhüt faaliyetine sahip projeler (yani birkaç dakika içinde birden fazla taahhüt) ve belki de uzun inşa süreleri olan projeler için anlamlı olabilir. Tabii ki yapıların nasıl kullanıldığına da bağlıdır. Test kullanıcıları için 15 dakika içinde birden fazla sürüm almak biraz kafa karıştırıcı olabilir ...

Ancak, hiçbir şey değişmezse inşa etmenin hiçbir anlamı olmadığını kabul ediyorum.

Bazı geliştiricilerin, bir işlevsel değişikliğe ait dosyaların tek bir atomik prosedürde işlenmeyeceği şekilde taahhütte bulunmasına izin verilmesini ister. Bazı “fiziksel taahhütlerden” oluşan bir “mantıksal taahhüt” yapmak için iki veya üç dakikaya ihtiyaçları vardır. Bu genellikle geliştiricilerin doğrudan DVCS kullanmadan merkezi bir depoya başvurduğu durumdur.

Bu durumda, CI sunucunuzun yeni bir derlemeye başlamadan önce son işlemden sonra bir süre beklemesine izin vermek iyi bir fikir olabilir. Ancak 15 dakika çok yüksek bir sayı gibi görünüyor, 5 dakika veya daha az yeterli olmalı.

Ya da daha iyisi (!), Geliştiricilerinizin yalnızca küçük bölümlerde çalışmasını sağlamaya çalışın, her seferinde yalnızca bir şey yapın ve yalnızca "işlevsel tam" fiziksel taahhütleri daha kolay hale getirin. Sonra her taahhütten sonra bir yapı görünüşte çalışacaktır.

Jenkins, bir projeye veya bağımlılıklarından herhangi birine yönelik bir kaynak denetimi taahhüdü oluşturmuş olsanız bile, bu, bir geliştiricinin önce kaynak denetimini taahhüt etmeden yapay depoya dağıtmasını engellemez. Eşsiz bir API değişikliği veya yapay veri havuzuna bağımlı bir hata dağıtırlarsa, bu, Jenkins işini tetiklemeden yapınızı bozabilir. Şahsen bu ASAP hakkında bilmek istiyorum.

İdeal olarak, her taahhüt için ve ayrıca az önce tanımladığım gibi durumları kontrol etmek için bir programda inşa edersiniz. Bu kavramsal olarak en az 15 dakikada bir inşa ettiğiniz anlamına gelir .

Jenkins işlerinizi bağımlılık artefakt dağıtımları üzerinde çalışacak şekilde ayarladıysanız (ve yaparsanız ... Bravo), birim testleriniz sağlamsa (yani bağımlılıkları test etmiyorlarsa) planlanan derlemeyi baltalayabilirsiniz. entegrasyon / fonksiyonel testler Jenkins işinin bir parçası değildir.

Bildiğim kadarıyla "e-posta ile sel" sorunu, ben kırık bir yapı üzerinde e-posta ile su basmak iyi bir şey olduğunu söylüyorlar. Geliştiricileri e-postaya bir açıklama ile yanıt vermeye zorladığınızdan emin olun ve kırık yapılarınızın yıkıldığını göreceksiniz, bana güvenin.

Onların akıl yürütmelerini anlayamayacağını söyledin, bu yüzden onlara sormalısın. Sadece ne istediklerini tahmin etmeyin ve bunu uygulamaya çalışın ve kesinlikle neden istediklerini anlamadan istediklerini uygulamayın.

Bununla birlikte, genel soruyu cevaplamak, kullandığınız kalkınma felsefesine bağlıdır. Her bir taahhüdün çalışması bekleniyorsa, her taahhüt test edilmelidir. Her itmenin çalışması gerektiği felsefesi ile bir DVCS kullanıyorsanız, her itmeyi test edin.

Genel olarak, insanlara bilmedikleri bir şey söylemek, sonra bildiklerini tekrarlamak daha iyidir. Örneğin, aldıkları gereksiz e-posta sayısını azaltmak istiyorlarsa, oluşturma sıklığını değil, e-posta ayarlarını değiştirin.