Dallanma sürekli entegrasyonu kırar mı?

Başarılı bir Git Dallanma Modeli olan bu makalenin deneyimli DVCS kullanıcıları arasında çok iyi bilindiğini düşünüyorum.

Kullandığım hgçoğunlukla, ama bu tartışma hiç DVCS için gayet iddia ediyorum.

Mevcut iş akışımız her geliştirici ana depoyu klonlar. Kendi yerel depomuza kod yazıyoruz, testleri gerçekleştiriyor ve eğer her şey yolunda giderse ustaya itiliyor.

Bu yüzden Jenkins gibi CI sunucularını kurmak ve gelecekteki hazırlık sistemi (şef, kukla, ansible, vb.) İle iş akışımızı iyileştirmek istiyoruz.

Gerçek kısım

Yukarıdaki model güzel çalışıyor ancak şubeler CI'yi kırabilir. Özellik dalı, developmentCI ve birleştirmeyi düzgün hale getirmek için orijiyle senkronize edilmelidir (makaleye göre, şube olacaktır ), değil mi?

Diyelim Alice ve Bob iki özellik üzerinde çalışıyorlar. Ama Alice ertesi gün yapılır. Bob'un özelliği bir hafta sürüyor. Bob bittiğinde, değişiklikleri eskimiş (belki Alice bazı sınıfları yeniden düzenledi / yeniden adlandırdı).

Bir çözüm, her sabah geliştiricilerin master/originherhangi bir değişiklik olup olmadığını kontrol etmek için çekmesi gerektiğidir . Alice söz verirse, Bob çalışma alanına çekilmeli ve özellik dalının güncel olmasını sağlamalıdır.

1. Bu iyi bir yol mu?
2. Bu dallar ana repoda mı bulunmalı (yerel klonda değil mi?) Her geliştiricinin yeni bir dal oluşturabilmeleri için GitHub / Bitbucket'teki ana repoya ayrıcalık vermesi gerekir mi? Yoksa bu yerel olarak mı yapılır?
3. Son olarak, dalları ile senkronize değilse makale tarafından sunulan model CI kırmak gerekir origin/master. Her gece inşa etmek istediğimizden, geliştiriciler işten ayrılmadan önce çekilmeli ve birleşmeli ve her özellik dalında da CI çalıştırılmalı mı?

Her şeyden önce, özellik dallarının (bir özellik üzerinde yapılan işi izole etmek için) ve CI'nin (işlendikleri anda entegrasyon sorunlarını bulmak için) biraz çelişkilidir.

Bence, özellik dallarında CI çalıştırmak zaman kaybıdır. Özellik dalları sık sık geldikçe, CI takımlarının tekrar tekrar yapılandırılması gerekecektir. Ve muhtemelen bir CI sisteminin tespit etmesi gereken sorunları önlemek için check-in'lerini koordine eden bir veya iki kaynaktan güncelleme alan bir şube için.
Bu nedenle, ana depo sunucusunda özellik dallarına sahip olmanın bir anlamı yoktur.

Soru 1 ve 3'e gelince: Ana geliştirme dalındaki yapının, özellik dalını içine birleştirdiklerinde kırılmamasını sağlamak geliştiricinin sorumluluğundadır. Bunu nasıl yaptıkları onların problemidir, ancak iki olası yol şunlardır:

• Ana geliştirme branşında yapılan değişiklikleri düzenli olarak özellik branşına çekin (örneğin günlük)
• Özellik tamamlandığında, ana geliştirme dalını özellik dalına birleştirin ve birleştirme sonucunu ana geliştirme dalına itin.

Her iki durumda da, bariz entegrasyon sorunları (örneğin, yeniden adlandırılmış sınıflar / dosyalar) bulunur ve önce özellik dalında giderilir. Daha ince konular büyük olasılıkla sadece gece yapıları çalıştığında bulunur ve orada düzeltilmelidir.

1'e yanıt olarak)

İşe yarayan herhangi bir yol iyi bir yoldur. Ancak : Sürekli Entegrasyon bütün öncül birleştirmektir sürekli . Fikir, entegrasyon hatalarını sadece mümkün olduğunca erken değil, aynı zamanda geliştirme geri besleme döngüsü içinde yakalamaktır - yani test edilen kodun tüm ayrıntıları, değişiklikleri yapan geliştiricinin kısa süreli hafızasındadır. Bu, normal şartlar altında, günlük koşullar altında, çalışmanın her taahhütteki özellik kollarına entegre edilmesi gerektiği anlamına gelir - belki de her 15 dakikada bir. Tekrarlamak için: Sürekli tümleştirmenin temel amacı, tüm ayrıntılar değişiklikleri yapan geliştiricilerin kısa süreli belleğindeyken entegrasyon hatalarını ortaya çıkarmaktır.

2)

Çoğunlukla, depolar klonlanarak Mercurial'ta dallar oluşturulur, bu nedenle her geliştiriciye ana repoya ayrıcalık vermeniz gerekmez. Bununla birlikte, muhtemelen, yerel olarak testleri çalıştırmak her zaman mümkün olmadığından, geliştiricilere sürekli entegrasyon sunucusunda klonlanmış depolar oluşturma yeteneği vermek istersiniz. (Bir zamanlar birim testlerin 128 çekirdek kümede 8 saat sürdüğü bir CI sistemim vardı) - Söylemeye gerek yok, geliştiriciler yapmadı, yerel olarak test yapamadı.

3)

Bunun için hesaplama kaynaklarına sahipseniz, evet, geliştiriciler her zaman, özellikle işten ayrılmadan önce ana geliştirme çizgisi ile tamamen güncel olmalı ve tüm geliştirme çizgilerinde bir gecede testler yapmalısınız (çoğu CI sistemi olmasına rağmen) bunu kolaylaştırmayın).

İşte bunu nasıl yapabilirsiniz: özellik dallanma.

1. Herhangi bir yeni görev için (bugfix, özellik vb.) Yeni bir şube başlatın (örn. Bugfix-ticket123-the_thingie_breaks)
2. Çalışırken, sürekli olarak güncelleyin ve varsayılanı (veya git'te master) özellik dalınıza birleştirin . Bu, varsayılan dalda çalışmak zorunda kalmadan şubenizi güncellemenize yardımcı olur
3. Özelliğiniz hazır olduğunda ve birim testleriniz geçtiğinde , varsayılanı bir kez daha dalınıza çekip birleştirin , dalınızı kapatın ve birleştirmeden itin , entegratörünüz yeni başı fark edecek ve kapalı bir dal olduğunu görecektir. bütünleştirmeye özen gösterir. Bir entegratörünüz yoksa varsayılana geçin ve özellik dalınızı varsayılana birleştirin .

Buradaki önemli şey , özellik dalınızı içine birleştirdiğinizde varsayılan dalda 0 çakışma olması ve tüm testlerinizin geçmesi .

Bu basit iş akışı ile her zaman bozulmamış ve istikrarlı bir varsayılan şubeye sahip olacaksınız, şimdi sürüm şubeleri için de aynısını yapın, ancak varsayılan olarak entegre edin . Düzeltmeleri doğrudan sürüm dallarına tümleştirmeniz gerekiyorsa, bunu varsayılan dalı atlayarak yine de yapabilirsiniz, ancak yine de, yalnızca hedef daldan yeni güncelleştirilen ve çakışma olmayan ve birim sınamaları geçen dalları seçerek yapabilirsiniz.