Sürekli bir entegrasyon sunucusu hangi noktada ilginçtir?


9

Jenkins gibi CI sunucuları hakkında biraz okudum ve merak ediyorum: hangi noktada yararlı?

Çünkü kesinlikle sadece 5 sınıf ve 10 ünite testine sahip olacağınız küçük bir proje için gerçek bir ihtiyaç yok.

Burada yaklaşık 1500 birim testimiz var ve 90 saniyede (eski Core 2 Duo iş istasyonlarında) geçiyorlar (çünkü gerçekten "birimleri" test ediyorlar ve bu nedenle çok hızlılar). Elimizdeki kural, bir test başarısız olduğunda kod işleyemeyeceğimizdir.

Böylece her geliştirici gerilemeyi önlemek için tüm testlerini başlatır.

Açıkçası, tüm geliştiriciler her zaman tüm testi başlattığından, bir geliştirici diğerini değiştirdiğinde (varsa) çakışan değişiklikler nedeniyle hatalar yakalarız.

Benim için hala çok net değil: Jenkins gibi bir CI sunucusu kurmalı mıyım? Ne getirecekti?

Sadece hız kazanımı için faydalı mı? (bizim durumumuzda bir sorun değil)

Eski yapılar yeniden oluşturulabildiğinden faydalı mıdır? (ancak eski devirleri kontrol ederek Mercurial ile bunu yapabiliriz)

Temel olarak bunun yararlı olabileceğini anlıyorum ama nedenini tam olarak göremiyorum.

Yukarıda ortaya koyduğum noktaları dikkate alan herhangi bir açıklama memnuniyetle karşılanacaktır.

Yanıtlar:


9

Sadece hız kazanımı için faydalı mı? (bizim durumumuzda bir sorun değil)

Sürecinizi döngüye sokarak geçirdiğiniz her zaman, geliştirme akışına girmek için harcayabileceğiniz zamandır.

İdeal olarak, doğrudan CD'ye yazılabilen, web'e yüklenebilen vb.

Eski yapılar yeniden oluşturulabildiğinden faydalı mıdır? (ancak eski devirleri kontrol ederek Mercurial ile bunu yapabiliriz)

Hayır, yapıları yeniden oluşturmazsınız. Oluşturduğu derlemeyi kullanırsınız ve saklama ayarlarınız dışarı çıkıncaya kadar onu saklarsınız.

Bunu, bazı Dev'in kutusunun aksine, inşa sunucusunda inşa edersiniz.

Burada yaklaşık 1500 birim testimiz var ve 90 saniyede (eski Core 2 Duo iş istasyonlarında) geçiyorlar (çünkü gerçekten "birimleri" test ediyorlar ve bu nedenle çok hızlılar). Elimizdeki kural, bir test başarısız olduğunda kod işleyemeyeceğimizdir.

Ayrıca kodunuzda otomatik entegrasyon veya uçtan uca testler yapmak ve birim testlerinin yakalamayacağı sorunları yakalamak istemez misiniz?

Bunları geliştirici kutularında çalıştırmak istemezsiniz, çünkü bu ortamı kurmak ve sürdürmek acı verici olacaktır. Entegrasyon testlerinin yürütülmesi de çok yavaştır.

hangi noktada yararlıdır?

Diğer yatırımlar gibi.

Bir kez kullanın ve geri gelebilir veya sadece kırılabilir. Birden fazla projede kullanın ve muhtemelen öne çıkacaksınız.

Ayrıca yaptığınız uygulamaların türüne de bağlıdır.

Bir Java Uygulama Sunucusu'na veya IIS'ye dağıtılması gereken web uygulamaları yaparsanız, CI beyinsiz hale gelir. Projenizin bir parçası olarak bir veritabanınız varsa aynı. Dağıtımın manuel olarak yürütülmesi acı vericidir ve KG ekibiniz (eğer varsa) bir noktada her gün bu kadar sık ​​ihtiyaç duyar.

Ayrıca, ihtiyaçlarınızın ve sorunlarınızın Joel Spolsky'nin 12 Adım Daha İyi Kod ile nasıl uyumlu olduğunu görmek isteyebilirsiniz . Özellikle 2, 3 ve 10 (hepsi ilginç ve önemli olsalar da).


2
+1 ... Tamam şimdi benimle konuşuyorsun! "Yapıyor kaybetme zamanı değil oluşturur" çok gibi argüman I. Yapımız günde birkaç kez yapılır ve sadece tek bir tıklama alır, ancak ... tüm testleri çalıştırmaktan daha yavaştır (böylece geliştiriciler zaman kaybediyor). Ayrıca, daha karmaşık testler fikrini seviyorum: Bu bir CI sunucusundan nasıl faydalanabileceğimizi görüyorum. 2,3 ve 10 ile ilgili olarak: evet, evet ve evet (bir Ant görevine tek bir tıklama) ... Ama adamım, bu 12 kural güncellenmeli: kaynak kontrolü kullanıyor musunuz? Örneğin, CVS'den ziyade sahip olmayı tercih ederim; ) (sadece yarı şaka;)
Cedric Martin

7

Hangi noktada yararlıdır?

  • Derleme + test döngünüz birkaç dakikadan fazla sürer. 5 dakikalık test çalıştırmasıyla, özellikle küçük değişiklikler için tüm testleri kendiniz yapmak istemeyeceksiniz.
  • Birden çok varyant oluşturmaya başlarsınız. Farklı özelleştirmelere sahip birkaç müşteriniz varsa, her bir varyant için testleri yapmalısınız, böylece iş miktarı oldukça hızlı büyümeye başlayacaktır. Daha sonra geliştirici makinesinde bir varyant için test paketini çalıştırırsınız ve geri kalanında çalıştırmak için CI'ye bırakırsınız.
  • Önemsiz bir test ortamı kurulumu gerektiren otomatik entegrasyon testleri yazıyorsunuz. Bir kanonik test ortamına karşı test etmek istediğinizden, geliştiriciler geliştirme değişiklikleri nedeniyle ortamlarını çeşitli şekillerde değiştirebilirler. CI, kanonik ortam için en uygun yerdir.
  • Testçiler en son yapıyı CI'den alabilirler. Bu nedenle ne geliştirme araçlarına sahip olmaları, öğrenmeleri ve kullanmaları gerekmekte ne de herhangi bir geliştiricinin yapılarını elle göndermeleri gerekmemektedir.
  • Serbest bırakılmaya hazırlanırken:
    • Test daha önemli hale gelir, bu nedenle test için hazırlanmış yapılara sahip bir yere sahip olmak daha da yararlıdır.
    • Tüm derlemelerin aynı derleme ortamıyla oluşturulduğundan eminsiniz, bu nedenle geliştirici yüklemeleri arasındaki küçük farkların neden olabileceği sorunlardan kaçınırsınız.
    • Sürüm kontrol sisteminde kontrol edilenleri tam olarak oluşturduğunuzdan eminsiniz. Geliştirme sırasında birisi bir şeyi kontrol etmeyi unutursa, oldukça hızlı bir şekilde bulacaksınız, çünkü bir sonraki geliştirici için başarısız olacaktır. Ancak böyle bir yapı KG veya üretime düşerse ve bir hata raporlarsa, izlemesi çok zor olur.

Muhtemelen henüz CI'ye ihtiyacınız yok, ancak test aşamasına geldiğinizde yararlı olacağını düşünüyorum. Jenkins birkaç saat içinde kurulur ve testinizi basitleştirir ve aptalca hatalardan kaçınmaya yardımcı olur (özellikle prodüksiyona hızlı bir düzeltme yaptığınızda gerçekleşir).


+1, teşekkürler. Ama bunu hiç anlamadım inşa argümanı: tüm geliştiriciler her hangi bir devir teslim ederse ve her biri makinelerinde tam olarak aynı yapıyı inşa edebildiklerinde uygulama daha sağlam değil mi? "Geliştiricinin hesabına bağlı yapılar" sorununu " CI sunucusuna bağlı yapılar" olarak değiştirmiyor muyuz ? Yani: CI sunucusunun kendisi yanlış yapılandırılmış olabilir ve bu nedenle yapı CI sunucusunun kurulumunun ince farkına bağlı hale gelir !? Bu yararlı olabilir biraz fark dedi: Ben sadece "yüklemek ve görmek" gerekir
:)

@CedricMartin: CI sunucusu yalnızca bir tanesidir, bu nedenle bunu yaptığınız ortamlar ile önceki derleme yaptığınız ortamlar arasındaki farktan kaynaklanan hatalarınız olmaz ve CI sunucusunda başka bir iş yapmadığınız için, onu kırmanız daha az olasıdır .
Jan Hudec

@CedricMartin: Açıkçası CI sunucusu yanlış yapılandırılmışsa, geliştiricilerin her zaman derleyeceği için yapıların geliştirici kutularında yapılanlardan farklı davrandığını fark edeceksiniz. Daha fazla kişi fark edebileceğinden, belirli bir geliştirici kutusunun yanlış yapılandırılmasından daha kolay.
Jan Hudec

6

Benim takımınızda 1'den fazla üye varsa bir CI ilginçleşiyor.

CI'yi "benim için testleri yapan başka bir bilgisayar" olarak düşünmeyi bırakmalısın. Tanımlanmış ve otomatik bir derleme süreci ve sürüm yönetimine sahip olmak için CI .

CI, yazılım sürümünüzü oluşturan tek yetkili varlıktır. CI üzerine kurulmazsa, olmadı.

Bir CI ile, yerinde olan tüm manuel ayarlamaları, korsanları ve kısayolları gösterecek ve sadece bir CI ile çalışmayan ve en başta kaçınılması gereken her şeyi otomatikleştirmek için kısıtlamalara sahipsiniz.

Kaçınılması gereken sorunlar:

  • Sürümün oluşturulmasından kim sorumludur?
  • Bu kişi 7/24 kullanılabilir mi?
  • Ama benim makine sendromumu temel alıyor
  • Yayınladığımız sürümün ne olduğu konusundaki tüm belirsizlikleri kaldırır

Avantajları (sadece bahsetmek için çok fazla):

  • Otomatik sürüm numaralandırma
  • Sorun izleme entegrasyonu
  • Otomatik metrik oluşturma
  • Statik kod analizi
  • Otomatik dağıtım
  • Çok Aşamalı kurulumlar

5

Sorunuzda mükemmel bir şekilde yansıtılan Sürekli Entegrasyon (CI) ile ilgili temel bir sorun var: CI uygulamalarının kurulumu ve savunması zordur çünkü CI sunucu yazılımı kurulum için önemsiz değildir ve projelerinizi bir CI üzerinden çalıştırmak ve çalıştırmak da önemsizdir sunucusu. Bununla, aslında CI'yi kucaklamanın kazancının nerede olduğunu görmek zorlaşıyor.

Her şeyden önce, CI içgörü ve kalite ile ilgilidir. İyi CI sizi projenize yaklaştırır, kalite metrikleri, dokümantasyon, kodlama standartlarına uyumluluk vb. Hakkında uygun geri bildirim sağlar. Tüm bunları kolayca görselleştirmek ve bir bakışta tanımanıza ve kolayca bir bakışta olmanıza olanak tanıyan araçlar sağlamalıdır. bir dizi değişikliği tüm bu proje metriklerinin belirli bir anlık görüntüsüyle ilişkilendirin.

Sadece ünite testleri yapmakla ilgili değil . Bir şey değil! Bu da beni kaliteye getiriyor. CI hataları kucaklar, onlardan kaçınmaz veya atmaz. Yaptığı şey, size daha sonra değil, erken hata yapmak için bir araç sağlamaktır. Dolayısıyla, daha önce test edilmiş bir kodu bir CI sunucusuna gerçekten işlemezsiniz. Her ne kadar temiz ve bozuk olmayan bir kod işlemeye çalışsanız da, aslında CI sunucusunu otomatik olarak bir entegrasyon oluşturucuyu kodunuz aracılığıyla otomatik olarak çalıştırmak ve her şeyin doğru olup olmadığını değerlendirmesini sağlamak için kullanırsınız. Varsa, temiz! Değilse, sorun değil - iyi CI uygulamaları, bir sonraki önceliğinizin kırılan her şeyi düzeltmek olması gerektiğini belirtir. Hangi, iyi bir CI sunucusunda, sizin için kolayca işaret edilmelidir.

Bir takımın büyüklüğü arttıkça, herkesin kodunun entegrasyonu doğal olarak zorlaşır. Tüm entegre parçaları test etmek ve bu yükü ekibin üyelerinden almak merkezi bir CI sunucusunun görevi olmalıdır. Bu nedenle, herkesin erken (ve mümkün olduğunca temiz) işlemesini ve ardından izleme durumunu oluşturur (genellikle bildirimler dahil edilir). Ve yine, bazı geliştiricilerin taahhüdü nedeniyle bir şey kırılırsa, hemen bunu düzeltmek ve bu otomatik yapıları hemen Tamam durumuna geri döndürmek onun sorumluluğu haline gelir.

Görüyorsunuz, bence her proje Sürekli Entegre olmaktan fayda sağlıyor. Mesele şu ana kadar ve bildiğim her bir CI sunucusundan akıl almaz karmaşıklık nedeniyle, insanlar daha küçük / basit projelerde CI uygulamalarını gerçekten savuşturdular. Çünkü, insanlar, çirkin, aşırı karmaşık, yetersiz teslim edilen, şişirilmiş bir yazılımı yapılandırarak gün geçirmekten daha iyi şeylere sahipler.

Aynı problemi yaşadım ve bu da yaklaşık bir yıl önce boş zamanlarımda Cintient'i geliştirmemi sağladı. Benim önceliğim, kurulumu, yapılandırmayı ve kullanmayı kolaylaştırmak ve herkesin hemen hemen başarısız olduğu ya da yetersiz çalışanların bu kalite metriklerini sunmasını sağlamaktı. Bu uzun cevaptan sonra, projenin GitHub bağlantısını işaret eden utanmaz fişim geliyor (ücretsiz ve açık kaynak, natch). Görünüşe göre bazı güzel ekran görüntüleri de var. :-) https://github.com/matamouros/cintient

Umarım sana yardımcı oldum.

(NOT: Bryan Oakley'nin yorumundan sonra, daha iyi bir cevap oluşturmak için daha fazla zaman harcamam gerektiği gerçeğinde düzenlendi. Ben de haklı olduğunu düşünüyorum.)


Aşağı oy verdim çünkü bu soruya cevap vermiyor, sadece bir reklam. Sorunun "şimdi, aracımla" örtük olarak ima etmek dışında ne zaman bir kısmına asla hitap etmiyorsunuz.
Bryan Oakley

@ Bryan-oakley tarafından önerildiği gibi, cevabı düzenlemek için biraz zaman ayırdım.
11:52

@matamouros: düzenleme iyi iş.
Bryan Oakley
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.