Sürekli entegrasyondan önce kaç tane geliştirici bizim için etkili olur?

Sürekli entegrasyonla ilgili bir ek yük vardır, örneğin, kurulum, yeniden eğitim, farkındalık faaliyetleri, veri sorunları olduğu ortaya çıkan, "hataların giderilmesi" için durdurma, vb.

Sürekli entegrasyon hangi noktada kendini öder?

EDIT: Bunlar benim bulgularımdı

Kurulum, VSS veya TFS'den okuyan, Nant'lı CruiseControl.Net'tir.

Kurulum ile ilgisi olmayan başarısızlığın birkaç nedeni:

Araştırma maliyeti : Kırmızı ışığın kodda, veri kalitesinde veya altyapı sorunu gibi başka bir kaynaktan (örneğin bir ağ sorunu, kaynak kontrolünden okuma zaman aşımı, üçüncü taraf sunucusu gibi) gerçek bir mantıksal tutarsızlıktan kaynaklanıp kaynaklanmadığını araştırmak için harcanan süre aşağı, vb.)

Altyapıya ilişkin politik maliyetler : Test çalışmasında her yöntem için bir "altyapı" kontrolü yapmayı düşündüm. Yapım sunucusunu değiştirmek dışında zaman aşımına karşı hiçbir çözümü yoktu. Bürokrasi yoluna girdi ve sunucu değişikliği olmadı.

Sabitleme Birim Testlerinin Maliyeti : Veri kalitesi sorununa bağlı kırmızı ışık, kötü yazılmış birim testinin bir göstergesi olabilir. Bu nedenle, kötü verilerden dolayı kırmızı ışık olasılığını azaltmak için verilere bağlı birim testleri yeniden yazılmıştır. Birçok durumda, birim testlerini doğru şekilde yürütebilmek için test ortamına gerekli veriler eklenmiştir. Verileri daha sağlam hale getirerek, bu verilere bağlı olması halinde testin daha sağlam hale geldiğini söylemek mantıklıdır. Tabii ki, bu iyi çalıştı!

Kapsama maliyeti, yani zaten mevcut kod için ünite testleri yazma : Ünite testi kapsamı sorunu vardı. Birim testi olmayan binlerce yöntem vardı. Bu yüzden, bunları oluşturmak için oldukça fazla sayıda erkek gününe ihtiyaç vardır. Bu, bir iş vakası sunmak için çok zor olacağından, ileriye dönük herhangi bir yeni kamu yöntemi için birim testlerinin kullanılmasına karar verildi. Birim testine sahip olmayanlara 'potansiyel olarak kızılötesi' denildi. Buradaki en ilgi çekici nokta, statik yöntemlerin, belirli bir statik yöntemin nasıl başarısız olduğunu benzersiz bir şekilde saptamanın nasıl mümkün olacağı konusundaki bir tartışma noktasıydı.

Ismarlama bültenlerin maliyeti : Nant scriptleri sadece şu ana kadar gider. Bunlar, EPiServer, CMS veya herhangi bir UI odaklı veritabanı dağıtımı için CMS'ye bağlı yapılar için faydalı değildir.

Bunlar, saatlik sınama işlemleri ve bir gecede kalite güvencesi oluşturma için derleme sunucusunda meydana gelen sorun türleridir. Bunların bir yapı ustası olarak gereksiz olmalarının, bu işleri serbest bırakma sırasında, özellikle tek kişilik bir grup ve küçük bir yapıyla gerçekleştirebildiklerini düşünüyorum. Bu nedenle, tek adımlı kurulumlar deneyimlerime göre CI kullanımını haklı göstermedi. Daha karmaşık, çok aşamalı yapılara ne dersiniz? Bunlar, özellikle bir Nant senaryosu olmadan oluşturulacak bir acı olabilir. Böylece, bir tane yaratmış olsanız bile, bunlar daha başarılı değildi. Kırmızı ışık sorunlarının giderilmesinin faydaları faydalardan ağır basmıştır. Sonunda, geliştiriciler ilgisini kaybetti ve kırmızı ışığın geçerliliğini sorguladı.

Adil bir deneme yaptıktan sonra, CI'nin pahalı olduğuna ve sadece işi yapmak yerine kenarlarda çok fazla çalışma olduğuna inanıyorum. Bir alarm sistemini tanıtmak ve sürdürmekten çok, büyük projelerden mahrum kalmayan deneyimli geliştiriciler kullanmak daha ekonomiktir.

Bu geliştiriciler giderse bile durum budur. İyi bir geliştiriciden ayrılıp ayrılmasının bir önemi yoktur, çünkü takip ettiği süreçler şartname özellikleri yazmasını, özellikleri tasarlamasını, kodlama kılavuzlarına sadık kalmasını ve kodunu okunabilir olması için yorumlamasını sağlar. Bütün bunlar gözden geçirildi. Eğer bu gerçekleşmezse, o zaman takım lideri işini yapmaz, bu da menajeri tarafından toplanmalıdır.

CI'nın çalışması için sadece birim testleri yazmak, tam kapsamı korumaya çalışmak ve oldukça büyük sistemler için çalışma altyapısı sağlamak yeterli değildir.

Sonuç olarak: Biri piyasaya sürülmeden önce birçok hatanın düzeltilmesinin bir işletme sorumlusundan bile istenip istenmeyeceğini sorgulayabilir. CI, müşterinin UAT'de belirleyebileceği bir avuç böceği veya garanti süresi sona erdiğinde, bir müşteri hizmet sözleşmesinin bir parçası olarak tamir için ödeme alabileceği çok sayıda çalışmayı içerir.

Bir CI motoru kurmak, evde bir yangın alarmı kurmaya benzer.

Aklımda faydalar birçok geliştiriciyle değil, büyük bir kod temeliyle ilişkilidir. CI motoru, kendin yapmak istemediğin tüm sıkıcı işleri aktif olarak yapar ve her zaman yapar.

Uzun süredir dokunmadığınız bir uzak modülü kırırsanız, derhal size söylenir. Sadece derleme akıllıca değil, aynı zamanda ünite testleri kurduysanız da işlevsel bir şekilde çalışır.

Ayrıca CI-motorunun montör kurulumu vb. Dahil olmak üzere tüm sıkıcı işleri yapmasına izin verirseniz , manuel olarak yapmanız gerekmediğini unutmayın. Sadece kaynağınızı kontrol edebilir ve bitmiş ürünün standart bir yerde kurulmasını bekleyebilirsiniz. (EDIT: CI motoru aynı zamanda iyi tanımlanmış bir ortamda çalışır, geliştiriciye özel kurulumlardan kaçınır, tekrarlanabilirlik sağlanır)

Bu aynı zamanda kalite güvencesinin bir parçasıdır.

EDIT: Yukarıdakileri yazdıktan sonra, Maven için Java oluşturma aracıyla ilgili deneyimim oldu. Temel olarak bu, CI konfigürasyonunun projenin içinde (pom.xml ile birlikte) tutmamızı sağlar, CI kurulumunu sürdürmeyi ve / veya başka bir CI motoruna geçmeyi çok daha kolaylaştırır.

Kaç geliştirici değil, 1'den n'ye (dahil) 1'den n'ye kadar olan adımların atılması ...

1: Kodu kontrol etme
Ve
n: kurulabilir \ konuşlandırılabilir paketleri olan

Eğer n <2 ise belki CI'ye ihtiyacınız olmaz
, CI'ya ihtiyacınız var

Güncelle
Bulgularınızı okuduğumuza, CI’ya yanlış yönden ve yanlış nedenlerden dolayı yaklaştığınıza karar verebilirim.

Bir takım için bile çabaya değer olabilir. Bu, özellikle çapraz platform kodu geliştirirken geçerlidir ve değişikliklerin her iki platformda da çalışacağından emin olmanız gerekir. Örneğin, Microsoft'un C ++ derleyicisi GCC'den daha fazla kabul ediyor, bu nedenle eğer Windows'ta geliştirirseniz, ancak Linux'u da desteklemeniz gerekiyorsa, bir CI sistemine sahip olmak, Linux'taki çöküşünüzün ne zaman büyük bir yardım olduğunu size söylemesidir.

Bazı CI sistemlerinin kurulması oldukça kolaydır, bu nedenle ek yükü gerçekten çok büyük değildir. Örneğin Jenkins veya Hudson'ı deneyin.

Söylediğiniz gibi kurma ve çalıştırmaya devam etmenin genel bir maliyeti var.

Ancak mola noktasının nerede olduğu sorusu ekibinizde kaç kişinin bulunduğunun bir fonksiyonu değil, projenizin uzunluğunun bir fonksiyonudur.

Bunu söyledikten sonra, gelecekteki tüm projelerinizde kullanabileceğiniz kurulum maliyetinin bir kısmı vardır, bu nedenle uzun vadede genel giderler sıfıra yaklaşabilir.

Jenkins bu hafta üzerinde üzerinde çalışıyorum küçük bir .NET projesi oluşturmak için ayarladım. Git kaynak kontrolümle entegre ettim, böylece her işte yapıyı tetikledi. Ünite testlerini yapıya dahil ettim. Statik analizleri FxCop ve StyleCop ihlalleri şeklinde entegre ettim.

Şimdi her kontrol ettiğimde, kodumun tamamını kontrol ediyor, inşa ediyor, sürüm montajını tüm montajlar arasında artırıyor, test ediyor, FxCop ve StyleCop ihlalleri için analiz ediyor, yapıyı arşivliyor ve sonuçları birkaç grafikte kaydediyor. Test sonuçları ve ihlallerin zamana karşı görünürlüğünü biliyorum.

Bunu sıfırdan yapmak bir saat kadar sürer (belki daha önce yapmadıysanız Google’la bir gün). Hiçbir şey ücretsizdir çünkü tüm araçlar ücretsizdir.

Proje inşa edildiğinde olduğu gibi, bedelsiz olarak büyüyecek kaliteli bir altyapıya sahibim. Yeni geliştiriciler projeye katılırlarsa veya katılsalar, çalışmaları ve projeye etkilerini ücretsiz olarak görebilirim.

Bu yüzden, CI'nin değmeyeceğini görebildiğim tek senaryo, ya bir gün kadar sürecek bir proje için ve sonra hiç bir zaman tekrar ziyaret edilmeyecek bir proje ya da mevcut / ücretsiz araçların bulunmadığı bir dilde ve bunları edinmenin maliyeti. İşe orantısız.

Her değişiklikten sonra projenizin tüm yönlerini doğrulayabilirseniz, CI'ye ihtiyacınız yoktur.

Diğer tüm durumlarda net kazançtır.

Tepegöz az. Bir adam için projeler faydalı olacağını söyleyebilirim. İkiye ulaştığınızda paha biçilmezdir.

Eğer bir kişi için "bir adım inşa / doğrula" seçeneğine sahipseniz, sürekli entegrasyon için uygun olabileceğiniz konusunda hemfikirsiniz, ancak bu durumlarda CI'yi ayarlamak için çok çaba harcadınız. resmi bir sistemde (CC, Hudson, TeamCity, vb.).

CI'in kendisi için ne zaman ödeme yaptığı sorusu, yeni bir projeye cevap vermek zor.

Mevcut bir projede, görmek çok daha kolay. Tedarik zincirinin geliştirme parçasında kritik bir hata bulursanız, sorunun mümkün olan en erken noktada bulunduğunu biliyorsunuzdur. Sabitleme maliyeti, şimdi en düşüktür. Bu problem gelişimin üzerindeki herhangi bir ortamda mevcutsa, maliyetiniz daha yüksektir.

Şimdi, yönetim bir hatayla serbest bırakılmaya karar verebilir, ancak bu bir iş riskidir. En azından şimdi, gecelik ücretlerle yapılan telefon görüşmeleri / paniklerden ziyade, bu risk değerlendirmesi ile hafifletilebilir, ki bunlar saatlik ücretlerle faturalandırılırlarsa, son derece pahalı olurlar.

Maliyet açısından göz önünde bulundurulması gereken bir başka şey. QA departmanınız nasıl? Manuel test mi? Eğer CI’ye giderseniz, genel senaryo maliyetlerini, bu komut dosyalarını geliştirme kutunuza göre otomatikleştirerek azaltabilirsiniz. Projenizi destekleyen QA milletvekillerinin sayısını CI aşamasına dahil ederek azaltabilirsiniz.

CI her zaman her zaman her zaman buna değer: Size verdiği güvenlik duygusu, mümkün olandan daha hızlı çalışmanıza olanak tanır. Sahip olduğunuz problem, birim testleri etrafında dönüyor gibi görünüyor. Birim testlerinin çok pahalı olduğu konusunda hemfikirim ama aynı zamanda (çoğu şey için) sahip olduğumuz en kötü seçenek olduklarını düşünüyorum. Şahsen ve üzerinde çalışmaya meyilli olduğum sistemler için, gerçek dünya ve (muhtemelen sentetik) patolojik vakaların bir kombinasyonu üzerinde çalışan sistem düzeyinde testlere yemin ederim; Birim testlerinden daha ucuzdur ve kavramsal evreninizin ulaşılması zor köşelerine girer: Donald Rumsfeld'in “Bilinmeyen Bilinmeyenleri”.

Her zaman, ekibin büyüklüğünden bağımsız olarak kullanın. Örneğin, sadece sizseniz, kim bilir, dizüstü bilgisayarınızdan starbucks'ta kod yazıyor olabilirsiniz, sonra evdeki beefier sisteminizden devam edebilirsiniz?

Genel gider gerçekten o kadar da kötü değil.

Bir. Evet, sürekli entegrasyon kullanmaya başlamak için bir tane yeterli.

Bu, kaç tane geliştirici olduğu değil,

a. Otomasyonu kullanarak ne kadar zaman kazandırır ve ne sıklıkta kullanırsınız.

• Entegrasyonlardan sonra binada zaman kazanma, otomatik testler yapma ve ayarlar oluşturma * giriş sıklığı = kaydedilen sürenin yüzdesi.

b. Kaç tane versiyonunuz / şubeniz / ürünleriniz var.

• İki farklı dalda çalışan bir geliştiriciniz varsa, her dalın oluşturulması, denenmesi ve paketlenmesi gerekeceğinden, tasarruf süresi iki katına çıkar.