Hangi Sürekli Entegrasyon çerçevesini kullanıyorsunuz ve neden? [kapalı]

Dışarıda epeyce farklı Sürekli Entegrasyon (CI) çerçeveleri var ve hangisinin en popüler olduğunu merak ediyorum. Çalıştığınız firmalarda hangi çerçeveleri kullandınız?

Bir CI çerçevesinin diğerinden daha popüler olmasının herhangi bir nedeni var mı - belki de bunun sunduğu özellikler, onunla bütünleşen şeyler veya belki de sadece pazarlaması ile mi ilgili?

Sürekli entegrasyon Java ve .net dünyalarında ruby ​​veya python demek yerine daha çok kullanılıyor gibi görünüyor. Bu neden?

Hudson veya Jenkins (ikincisi birincinin çatalı). Sebep: Basit (kurulumu ve kullanımı basit) ve büyük esnekliğe sahiptir. Eklentiler, düşünebildiğim hemen hemen her işlevi ekler.

Birkaç yıl önce hasar kontrolü kullandım . Ayrıca kullanımı basitti, ancak eklentileri yoktu. Ancak yazar, basit çözümden vazgeçeceğine ve birbiriyle iletişim kuran farklı sunuculardan oluşan yeni bir sürüm geliştirmeye başlamasına karar verdi (ne cehennem?). Bu işe yaramadı ve proje pes etti. Bir süre aradım, ama ne cruisecontrol (çok karmaşık) ne de süreklilik beni gerçekten etkiledi. Hudson'a kadar bu benim için ilk andan itibaren işe yaradı.

Kullandığım TeamCity iş yerinde ve evde. Çeşitli inşaat rayları için büyük desteğe sahiptir ve eklentiler yoluyla genişletilebilir.

Yapılandırma için XML yığınlarıyla uğraşmamak kitaplarımda çok büyük bir artı ve ücretsiz sürüm ev ihtiyaçları için yeterli.

TeamCity ile karşılaştığım bir sorun, otomatik olarak .NET derlemelerini sürümüne getirmeye çalışmakla ilgili. Nispeten karmaşık bir geçici çözüm kurmak zorunda kaldım, ancak bir kez yerine oturduğunda bir cazibe gibi çalıştı.

Şahsen, sadece hiç CruiseControl ve CruiseControl.Net kullandım. Bunun nedeni ekonomi ile ilgili. Oldukça stabildirler ve onları bir kez kurduğunuzda, sürdürmek için yapmanız gereken çok az şey vardır. Kullanıcı topluluğu genellikle çok yardımcı olur ve ihtiyaçlarınıza göre genişletilebilir.

Bununla birlikte, daha iyi bir kurulum deneyimi ve ticari destek sunan, farkında olduğum (biri JetBrains, diğeri Atlassian tarafından) tanıdığım birkaç ticari teklif var. Bu teklifleri denemek istemiştim ama henüz bir şansım olmadı.

CI araçlarının, derlenmiş dillerle oynamak için yorumlanmış dillerden daha önemli bir rolü vardır, ancak bu CI aracının çevrilmiş dillere harcandığını söylemek değildir. Birbirinize bağlı birkaç projeniz olduğunda ve bir değişikliğin yanlışlıkla bağımlılıklarını bozmadığından emin olmak istediğinizde - CI araçları paha biçilmezdir.

CI araçlarının yakalamanıza yardımcı olabileceği üç genel sorun sınıfı vardır:

1. Hataları derleme - eğer bir sınıfın imzası bağımlılıkları kıracak şekilde değişirse, bir teslimatın geçen saatlerinden önce bunu bilmek en iyisidir.
2. Mantık hataları - Bir sınıfın davranışı bağımlılıkları kıracak şekilde değişiyorsa, bunu önceden bilmek en iyisidir. Bu, en çok ünite testi olmak üzere bir tür otomatik test tarafından kontrol edilmelidir.
3. Kabul Testi - bitmiş ürün üzerinde çalışacak otomatik bir test grubunuz varsa, bunları sık sık çalıştırmak en iyisidir.

Yorumlanan diller derlenmez, bu nedenle yakalanacak derleme hatası yoktur. Bununla birlikte, diğer iki problem, CI araçlarının Ruby / Python / Perl / etc içindeki projeler için faydalı olduğu kadar yaygındır.

Hem mantık hatalarındaki hem de kabul test noktalarındaki anahtar kelime "otomatik" testtir. Bir makinenin çalışabileceği bir test takımınız yoksa, CI araçlarının büyük yararlarını kaçırıyorsunuz demektir. Otomatik süitler zamanla oluşturulabilir, böylece küçük başlayabilirsiniz.

Düzenle

Çok sayıda CI Aracı'nın (çoğu tanımadığım) özellik karşılaştırması için bu hoş tabloya bakın:

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

Takım Temel Sunucusu

Solid CI, Visual Studio ile sıkı entegrasyon ve sürüm kontrolü olarak Git . Hudson gibi daha esnek CI Sunucuları gördüm, ancak TFS'nin diğer ürünlerle olan sıkı entegrasyonu, deneyimi ekibim için anlamlı olacak kadar sorunsuz hale getiriyor.

Ben ikisini de kullanmak cruisecontrol.net ve Hudson . Yaptıklarımın bazıları bir tanesinde, bazıları da diğerinde.

Niye ya? Çünkü ben inşaat mühendisi değilim ve o inşaat mühendisi kim onları böyle ayarladı!

Yapımlarımın kurulmasında ya da herhangi bir ürünle ilgili şikayetlerde sorunum yok. Size olayların burada nasıl olduğunu bildiriyorum, gerçekte ve bu bakış açısını takdir edersiniz!

GÜNCELLEME: Cevabı gönderdiğimden beri, Hudson çatallanmış ve Jenkins olmuştur . Yukarıdaki öneri Jenkins için geçerlidir.

Pulse . Temelde yoğun inşaat mühendisi için çok önemli olan Just Works. Ayrıca gerçekten mükemmel teknik destek var. Bu kadar çok sevmemin asıl nedeni 250'den fazla projemiz olması ve onları hıçkırık olmadan ele alması; Hudson için aynı şeyi söyleyemem.

Ekibimiz ağırlıklı olarak Python, C ++ ve Java ile çalışmaktadır. CI için Buildbot kullanıyoruz. Başlangıçta bununla başladık çünkü Trac ile bütünleşiyor ve basit ve anlaşılır görünüyordu. Python dünyasında CI seçim çerçevesi olduğuna inanıyorum.

Hudson. Bazen küçük bir sorun olur ve daha ilginç eklentilerden bazıları aslında işe yaramıyor, ancak küçük bir tutamaçta oldukça kullanışlı.

Muhtemelen bunun yerine Pulse kullanırdım, ancak birden fazla platformda inşa etmeniz gerekiyorsa, bu biraz fazla.

Sürekli entegrasyon için CruiseControl.NET . Oldukça iyi çalışır, ancak CruiseControl'de kurduğumuz çok sayıda yapım projesiyle CCTray masaüstü tepsi uygulaması, uzun yenileme aralıklarında bile korkunç derecede duyarlı değildir.

NAnt , CruiseControl projelerinde derlenen komut dosyaları içindir. Daha karmaşık derleme komut dosyaları için NAnt'yi özel C # NAnt görevleri ile genişlettik, bu çok güzel - C # kodunu yazmak NAnt komut dosyaları oluşturmaktan çok daha keyifli.

Biz bir Microsoft mağazayız ve Teorik olarak Team Foundation Server ortamımızı 2010'a geçirdikten sonra Microsoft Team Build 2010'a geçiyoruz.

Uygulamanızı, çalışan bir CI-motorunuz olmasına bakılmaksızın, komut satırından oluşturabiliyor olmanız gerektiğini unutmayın.

Bu, tüm CI-motorunun yapı çağrılarınızı sistematik hale getirdiği ve özel gereksinimlerinize en uygun motoru seçebileceğiniz anlamına gelir.

Aslında, Hudson'ı seviyorum, çünkü öncelikle " iyi hissettiriyor" , ama herkesin başarısız olması durumunda, fazla çaba harcamadan başka birine geçebileceğimi biliyorum. Öyleyse, ilk önce Atlassian tarafından yapılanları araştırırım, çünkü yaptıkları diğer programların "hissini" seviyorum .

Değiştirilebilirliğin, hangi dilde yazıldığının önemli olmadığını ima ettiğini unutmayın. Java'nın birçok motor için seçildiğine inanıyorum, çünkü birçok platform destekleniyor, birçok yapı taşı ile kolayca kullanılabilir. Bir web sunucusuna ihtiyacınız var - birini alın. Birçok eşzamanlı iş parçacığına ihtiyacınız var - sadece onları kullanın. Genişletilebilirlik gerekir - bir kavanozun içine bırakın.

"Sürekli entegrasyon" terimini daha önce duymadan önce (Bu, 2002 veya 2003’te geri döndü), cvs’e bağlı, ana projenin temiz bir kopyasını ve daha küçük olan beş alt projenin kopyasını almış bir derleme betiği yazdım. karınca yoluyla kavanozlar daha sonra tomcat karınca görevlerini kullanan ikinci bir karınca betiği ile bir WAR dosyası oluşturup yeniden konuşlandırdı.

Saat 19: 00'da cron aracılığıyla çalıştı ve bir sürü ekli çıktı dosyası içeren bir e-posta gönderdi. Projeyi 7 ay boyunca kullandık ve önümüzdeki 20 ay boyunca bakım ve iyileştirmeler için kullanımda kaldı.

İyi çalıştı ama hala bash betiği, cron ve karınca hudson tercih ederim.