DVCS'ler sürekli entegrasyonu engeller mi?

Diyelim ki on çevik geliştiriciden oluşan bir ekip var. Her gün her biri yönetim kurulundan bir görev seçer, (günün sonunda) görevi tamamlayana kadar kendisine karşı çeşitli değişiklikler yapar. Tüm geliştiriciler doğrudan gövdeye karşı check-in yaparlar (Google tarzı, her işe alım özelliği, özellik geçişleri vb. Kullanarak serbest bırakma adayıdır).

SVN gibi merkezileştirilmiş bir CVS kullanıyorlarsa, bunlardan her biri işlediğinde, derleme sunucusu değişikliklerini diğer dokuz geliştiricinin çalışmasına karıştıracak ve test edecektir. Derleme sunucusu gün boyu sürekli çalışıyor olacak.

Ancak git gibi bir DCVS kullanıyorlarsa, geliştirici bütün yerel taahhütlerini merkezi depoya bir araya getirmeden önce görevi tamamlayana kadar bekleyebilir. Değişiklikleri gün sonuna kadar bütünleşmeyecek.

Bu senaryoda, SVN ekibi sürekli olarak daha sık entegre oluyor ve entegrasyon sorunlarını git ekibinden çok daha hızlı keşfediyor.

Bu, DVCS'lerin sürekli ekipler için eski merkezi araçlardan daha az uygun olduğu anlamına mı geliyor? Bu ertelenmiş sorunla nasıl başa çıkacaksınız?

Yasal Uyarı: Atlassian için çalışıyorum

DVCS, geliştiriciyi kendi branşlarına düzenli olarak uzaktan ittiği ve CI sunucusunun bilinen aktif dalları oluşturması için kurulum yaptığı sürece Sürekli Entegrasyondan vazgeçmez.

Geleneksel olarak DVCS ve CI ile iki problem vardır:

• Entegrasyon durumunun belirsizliği - geliştirici ustadan düzenli olarak birleşmediği ve yapıyı yönetmediği sürece, birleşik değişikliklerin durumunun ne olduğunu bilmiyorsunuzdur. Geliştiricinin bunu manuel olarak yapması gerekiyorsa, problemleri yeterince erken almak için yeterince sık yapılmayacağına dair ihtimaller vardır.
• Yapı yapılandırmasının çoğaltılması ve sürüklenmesi - yapı yapılandırmasının, bir şube oluşturma oluşturmak için bir 'ana' yapıdan kopyalanması gerekiyorsa, şube için yapılan yapılandırma, kopyalandığı yapıyla hızla eşzamanlı hale gelebilir.

Bamboo'da, yapı sunucusunun geliştiriciler tarafından oluşturulmuş yeni dalları tespit etme ve master için yapı yapılandırmasını temel alarak şube için otomatik olarak kurulum oluşturma özelliğini sunduk (bu yüzden, master yapısını değiştirirseniz, dalları yapılandırmayı da değiştirir) değişikliği yansıtmak için).

Ayrıca, şube oluşturma çalıştırılmadan önce dalı master ile yapılan değişikliklerle güncellemek veya dallar arasındaki değişikliklerin mümkün olan en kısa sürede birlikte test edilmesini sağlamak için başarılı bir derleme dalındaki değişiklikleri otomatik olarak itmek için kullanılabilecek Birleştirme Stratejileri adlı bir özelliğe sahibiz. .

Her neyse, daha fazlasını öğrenmekle ilgileniyorsanız, "Sürekli Entegrasyon ile Özellik Branşlarını Etkinleştirme" blog yazımı görün

Küçük ekibim bir veya iki yıl önce bir DVCS'ye geçti ve şirketimin geri kalanı birkaç ay önce dava açtı. Tecrübelerime göre:

• Merkezi bir VCS kullanan insanlar, büyük bir proje yaparken hala taahhütte bulunma eğilimindedir. Bu DVCS'lere özgü bir sorun değildir. Bir taahhütte bulunmadan önce birkaç gün bekleyecek değişiklik setlerine sahip olacaklar. En büyük fark, bu sırada bir noktada bir hata yaparlarsa veya bilgisayar çökerse, onu düzeltmek için çok daha fazla çaba gerektirir.
• Her geliştiricinin kendi adına adlandırılan şubesinde çalıştığı ve yalnızca kodunu gözden geçiren kişinin değişikliklerini kafada birleştirmesine izin verilen bir iş akışı kullanıyoruz. Bu, sorunlara neden olma taahhüdünün olasılığını azaltır, bu nedenle derleme sunucusu bir hata mesajı ürettiğinde insanlar gerçekten dikkat eder. Aynı zamanda, diğer geliştiricilerin, kafa sabitlenene kadar kendi branşlarında çalışmaya devam edebilecekleri anlamına gelir.
• Bir DVCS'de insanlar kodlarını kafa ile birleştirmeden önce programlama için daha fazla zaman harcarlar . Bu yüzden yapının devamlılığına biraz gecikme getirme eğilimindedir. Ancak bu fark, DVCS'nin avantajlarını karşılayacak kadar önemli değildir.

Geçenlerde Mercersial'ı SubVersion Üzerinden (ben bir yıkım geekiydim ) kullanan yaklaşık 19 projede gözlemledim : geliştiriciler kendi branşlarında çalışarak ve yalnızca hizmet günleri veya haftalarından sonra bütünleşerek gerçekten bireyci olmaya başladı. Bu ciddi entegrasyon sıkıntılarına ve endişelerine neden oldu.

Karşılaştığımız diğer bir problem ise sürekli entegrasyon sunucusudur. Sorunların bildirilmesi (örneğin başarısızlık testi), ancak taahhütlerin senkronizasyonu sunucuya yapıldığında yapıldı.

Martin Fowler'ın kendi sitesinde yazdığı anlaşılıyor .

Bununla birlikte, bahsettiğim projenin bir kısmı sorunları en az günde bir kez senkronize etti. Bu yüzden DVCS sizce, sorunuzun cevabı olabilir sürekli entegrasyon cesaretini ve bireyciliğe artırır. Ancak, DVCS doğrudan nedeni değildir.

Geliştirici, kullandıkları VCS'den bağımsız olarak hala sorumludur.

Sebeplerinizi temel aldığınız fikir çok titrek, yumuşak konuşur. Geliştiricinin görevi tamamlayana kadar bekleyebileceği ekip / yönetim / süreç sorunudur .

Öyle ya da böyle yapıyor, "bekle" ya da "acele et", paylaşılan bagaj ya da izole dal, dallanma stratejisi olarak bilinir ve çevrimiçi olarak mevcut bilgileri inceliyorsanız, belirli bir stratejiyi seçmenin temelde yapabileceği bir şey olmadığını göreceksiniz. VCS'nin merkezileştirilmesi veya dağıtılması.

Diyelim ki Mercurial gibi dağıtılmış VCS'ler için sık sık yapılan birleşimler için kolayca güçlü tavsiyeler bulabilirsiniz :

İlk olarak, sık sık birleştirin! Bu, herkes için birleşmeyi kolaylaştırır ve daha önce (genellikle uyumsuz tasarım kararlarına dayanan) çatışmaları keşfedersiniz ...

Yukarıdaki gibi öneriler incelendiğinde, bunların Mercurial dağıtımı ile ilgisi olmayan konulara dikkat çekildiği kolayca anlaşılabilir.

Şimdi merkezi VSC, Subversion tarafındaki duruma bakalım. Çevrimiçi bilgileri inceleyerek, her biri birleşme sıklığı üzerinde ters etki yaratan kararlı gövde ve dengesiz gövde denilen en popüler stratejiler arasında bulabilirsiniz . Görüyorsunuz, insanlar VCS'nin merkezileşmesine bile dikkat etmeden bir şeyi yapmanın bir yolunu seçiyorlar.

• ^{Merkezileştirilmiş VCS ile ciddi gecikmeli birleşme yaşandığını (hatta topal yönetim tarafından teşvik edildiğini) ve ayrıca DVCS ile yapılan sık sık birleşmelerin ekip / yönetimin doğru olduğunu düşündüğünü gördüm. VCS'nin bir şekilde karar vermek için dağıtıldığını ya da merkezileştirildiğini kimsenin umursamadığını gördüm.}

Yukarıda verilen, DVCSes'in sürekli entegrasyonu engelliyor mu? olacaktır Mu .

VCS'nin dağıtılması veya dağıtılmaması bunun üzerinde önemli bir etkiye sahip değildir.

Tecrübelerim tam tersi , svn kullanan ekipler günlerce zorlanmayacak , çünkü üzerinde çalıştıkları kod sandıkların elle birleştirmeye zaman kaybetmeden herkes için derlenmemesine neden olacak . Sonra sprint sonuna yakın, herkes taahhüt eder, deliliğin birleşmesi gerçekleşir, işler fazla yazılır, kaybedilir ve iyileşmeleri gerekirdi. CI sistemi KIRMIZI olur ve parmakla işaret verilir.

Git / Gitorious ile hiç bu problem yaşamadım.

Git, başkalarının değişikliklerini sizin isteğinize göre çekip birleştirmenize olanak tanır, bir başkası bir şeyi kontrol ettiğinden ve teslim almak istediğinizden değil, 20 dakika el ile birleştirme işlemini yaptığınızdan.

Git ayrıca, başkalarının taahhütlerini almanıza, kodunuzu birleştirmenize ve çalışan bir sürümü herkese zorlamanıza izin verir, böylece değiştirdiğiniz şeye bağlı olarak ne birleştirmeleri gerektiğini tahmin etmeleri gerekmez.

Birleştirme istekleri yoluyla kod incelemeleri için aracı olarak Gitorious gibi bir şeye sahip olmak , pek çok şubenin ve birçok katılımcının yönetimini çok acısız hale getirir.

Bir Git deposundaki tüm aktif dalları izlemek için Jenkins / Hudson'u kurmak da çok kolaydır. CI ile daha fazla çekiş ve SVN'den Git'e geçtiğimizde depoların durumu hakkında daha sık geri bildirim aldık.

Sunucu oluşturma ucuzdur. Sadece CI sunucunuzun bildiğiniz tüm şubeleri toplamasını sağlayın.

Jenkins, birden fazla git deposunu kontrol etmeyi ve tek bir işte bulunanların herhangi birinden 'en sonları' almayı desteklemektedir. Diğer araçlarla benzer çözümler olduğundan eminim.

Bu eski soru yeni bir sorunun kopyası olarak işaretlendi ve cevapların çoğu modası geçmiş fikirlere atıfta bulunduğundan, güncellenmiş bir yazı göndereceğimi düşündüm.

Beş yıl önce görünüşte yaygın olmayan bir şey, çekme talebi dallarında master'ı birleştirmeden önce CI testleri yapıyordu. Bu birleştirme sıklıkla arzu edilmekle beraber, paylaşmak bir tavır değişikliğini yansıtıyor düşünüyorum her ile değişiklik herkes , kısa sürede bunu yaparken , optimum değildir.

DVCS, taahhütlerinizi entegre etmek için daha hiyerarşik bir mod yarattı. Mesela, sık sık yanımda oturan geliştiriciyle çok yakından ilgileniyorum. Günde birkaç kez birbirimizin kollarından çekeceğiz. Bugün, birkaç saatte bir çekme isteğine gönderilen değişiklikler aracılığıyla başka bir geliştirici ile işbirliği yaptık.

Derleme komut dosyalarında kapsamlı değişiklikler yapıyorduk. Jenkins yerel olarak her PR şubesini ana ile birleştirir ve testler yapar, bu nedenle temiz bir yapıya ihtiyaç duyan herhangi bir geliştiriciyi rahatsız etmeden otomatik geri bildirim aldık. PR, üç geliştirici grubumuz dışında ustalaşmaya ve paylaşmaya katılmaya hazır olmadan önce bir gün daha geçecek.

Bununla birlikte, birileri değişikliklerimizin bir araya gelmesini bekleyemezse, çünkü değişiklikleri bizimkine bağlı olduğu için, dev şubemizi yerel olarak birleştirebilir ve çalışmalarına devam edebilir. CVCS'ye alışkın olan birçok insanın özlediği şey budur. CVCS ile değişikliklerinizi paylaşmanın tek yolu, onları merkezi depoda birleştirmektir ve bu yüzden birleşme çoğu zaman daha önemlidir. DVCS ile başka seçenekleriniz de var.

DVCS'nin sürekli entegrasyon için daha elverişli olduğunu söyleyebilirim. Birleşmeler onlarla aynı derecede rahatsız edici değildir. Ancak daha fazla disiplin gerektiriyor. Birleştirmek için tabandan bir çekme ile yerel bir taahhüdü takip etmeli ve göreviniz tamamlandığında (bir sonrakine geçmeden önce) itmelisiniz.

Ekibim Git’e geçtiğinde, sürecimizin açıkça eski bir VCS’de olduğu gibi bir itiraz olarak değerlendirileceği ve yerel taahhütlerin her bireyin istediği kadar / sıkça yapılabileceği şekilde açıkça ortaya konduk. Bununla birlikte, DVI veya merkezi bir VCS kullanıp kullanmadığımızdan CI sisteminde hiçbir fark yoktur.

Cevap hem evet hem hayır.

Buradaki fark, doğrudan merkezi CI görüntülenen repoyu işlemek ve değişikliklerinizi merkezi CI görüntülenen repo'ya itmek arasındadır. Bulabileceğiniz 'problem', DVCS kullanıcılarının gerçekte düzenli olarak bu işlemi yapamayabileceği yönündedir.

Bunun bir DVCS'nin doğal tasarım özelliği olduğunu söyleyebilirim, değişikliklerinizi her zaman merkezi sunucuya göndermek için tasarlanmadı - eğer öyleyse, bunun yerine bir CVCS de kullanabilirsiniz. Yani cevap, geliştiricileriniz arasında daha iyi bir iş akışı sağlamaktır. Her gece değişiklik yapmalarını söyle. Simples!

(Eğer SVN kullanıcılarınız her gece taahhütte bulunmuyorsa, onlara da - aynı problemi söyleyin).

Git sürekli entegrasyonu engellemiyor. Bagaj tabanlı iş akışınız.

Bu, sezgisel görünebilir gibi gelebilir, ancak: geliştiriciler özellik dalları üzerinde çalışırlarsa, sık sık kendi makinelerine entegre olmaları için teşvik edilebilirler (ve birleştirme özelliklerini göndermeden önce bunu yapmaları gerekir). Buna karşılık, gövde tabanlı bir iş akışı daha büyük taahhütler ve dolayısıyla daha az sıklıkta entegrasyonu desteklemektedir.

Google tarzı gövde tabanlı bir iş akışının, birleştirmenin kolay olduğu Git gibi bir VCS ile üretken olduğunu düşünüyorum. İşte bunun yerine tavsiye ediyorum:

• Özellikleri kırın, hiçbiri geliştirmek için bir veya iki günden fazla zaman almayacak kadar küçüktür.
• Her özellik özel bir dalda geliştirilmiştir.
• Geliştirici özel şubeyle sık sık bütünleşir ( git fetch origin; git merge master). Bu şekilde çalışırken genellikle bunu günde birçok kez yapıyorum.
• Geliştirici birleştirme ve inceleme için şube gönderdiğinde, CI sunucusu otomatik bir derleme yapar. Birleştirme yalnızca bu başarılı olduğunda gerçekleşir.

İşte orada: küçük komisyonlar, sık entegrasyon ve hangi özelliğin hangi özelliğe ait olduğuna dair izlenebilir bir tarih. Doğru kullanılan dallar Git için değerli olan her şeyin anahtarıdır, onlardan kaçınmak büyük bir hatadır.

Jdunay'ın bahsettiği gibi müthiş teknik çözümler var, ama bizim için bu bir insan sorunu - aynı şekilde insanların svn için taahhütte bulundukları bir ortamı teşvik etmenin de bir insan sorunu olduğu gibi.

Bizim için çalışan şey şudur: (master master’ı şu anda aktif olan dev şubesiyle değiştiriniz)

1. Master’dan sıkça yapılan birleştirme / yeniden yazma işlemleri
2. Ustalaşmak için yeterince sık iter

3. Belirli yeniden yapılandırmalar gibi cehenneme neden olan şeylerin farkındalığı ve bunu iletişim yoluyla hafifletmek. Örneğin:

   • Öğle yemeğinden önce herkesin ittiğinden emin olun
   • Öğle yemeğinde refactoringi uygulayın ve itin
   • Herkes öğle yemeğinden sonra çeker emin olun