Sürekli entegrasyon yaparken en iyi dallanma stratejisi?


100

Sürekli entegrasyon yapmak istediğinizde kullanabileceğiniz en iyi dallanma stratejisi nedir?

  1. Yayın Dallanma: gövdede geliştirin, her sürüm için bir dal tutun.
  2. Özellik Dallanma: her özelliği ayrı bir dalda geliştirin, yalnızca kararlı bir kez birleştirin.

Bu stratejilerin ikisini birlikte kullanmak mantıklı mı? Olduğu gibi, her sürüm için dallanıyorsunuz ama aynı zamanda büyük özellikler için de dallanıyorsunuz? Bu stratejilerden biri sürekli entegrasyonla daha iyi örtüşüyor mu? Kararsız bir devre kullanırken sürekli entegrasyon kullanmak mantıklı olur mu?


2
Yan not: Bazıları, yeni özellikler konulsa bile, her şeyin her zaman kararlı olması gerektiğini savunabilir. Öte yandan, bu biraz idealist olabilir.
Keith Pinson

Yanıtlar:


21

Günlük işimde ağırlıklı olarak şubelere dayandığım için konuyu gerçekten ilginç buluyorum.

  • Mark Shuttleworth'un geleneksel CI'nın ötesine geçerken ana şubeyi bozulmadan tutmaya yönelik bir model önerdiğini hatırlıyorum. Bunun hakkında burada yazdım .
  • Cruise Control'e aşina olduğum için, burada görev dalları ve CI hakkında da blog yazdım . Plastik SCM ile nasıl yapılacağını açıklayan adım adım bir öğreticidir .
  • Son olarak, Duvall'ın CI hakkındaki kitabında CI ile ilgili (ve potansiyel olarak dallanma hakkında konuşulan) bazı konuları da çok ilginç buldum .

Umarım bağlantıları ilginç bulursunuz.


Bamboo'a her görev için dallanma desteği ekledik codicesoftware.blogspot.com/2012/02/… ve en yeni sürümleri, dvcs de dahil olmak üzere çeşitli sürüm kontrolleriyle bunu yerel olarak yapacak gibi görünüyor.
pablo

20

Cevap, ekibinizin büyüklüğüne ve kaynak kontrolünüzün kalitesine ve karmaşık değişim setlerini doğru bir şekilde birleştirme yeteneğine bağlıdır. Örneğin, CVS veya SVN birleştirme gibi tam şube kaynak denetiminde zor olabilir ve ilk modelle daha iyi durumda olabilirsiniz, IBM ClearCase gibi daha karmaşık bir sistem kullanıyorsanız ve daha büyük bir ekip ile ikinci modelle daha iyi olabilirsiniz. model veya ikisinin bir kombinasyonu.

Kişisel olarak, her bir ana özelliğin ayrı bir dalda geliştirildiği özellik dalı modelini, her bir geliştirici tarafından yapılan her değişiklik için görev alt dallarıyla ayırırdım. Özellikler stabilize edildikçe, makul ölçüde sabit tuttuğunuz ve her zaman tüm regresyon testlerini geçtiğiniz gövdeyle birleştirilirler. Sürüm döngünüzün sonuna yaklaştığınızda ve tüm özellik dalları birleştikçe, gövde bir sonraki sürümün geliştirilmesi için kullanılırken, üzerinde yalnızca kararlılık hata düzeltmelerini ve gerekli arka yuvaları yaptığınız bir sürüm sistemi dalını stabilize eder ve dallandırırsınız. yeni özellik dalları için dallanma. Ve bunun gibi.

Bu şekilde, gövde her zaman en son kodu içerir, ancak onu makul ölçüde kararlı tutmayı, büyük değişiklikler ve özellik birleştirmelerinde kararlı etiketler (etiketler) oluşturmayı başarırsınız, özellik dalları, sürekli entegrasyon ile hızlı tempolu geliştirmelerdir ve bireysel görev alt dalları genellikle olabilir Farklı özellikler üzerinde çalışan diğer ekipleri etkilemeden aynı anda herkesin aynı özellik üzerinde çalışmasını sağlamak için özellik dalından yenilenmiştir.

Aynı zamanda, geçmişte, herhangi bir nedenle ürününüzün önceki sürümlerinde veya hatta en son yayınlanan sürümünde kalan müşterileriniz için arka plan, destek ve hata düzeltmeleri sağlayabileceğiniz bir dizi sürüm şubesine sahipsiniz. Ana hatta olduğu gibi, sürüm dalları üzerinde sürekli entegrasyon kurmazsınız, bunlar tüm regresyon testlerini ve diğer sürüm kalite kontrollerini geçtikten sonra dikkatlice entegre edilir.

Herhangi bir nedenle iki özellik birbirine bağımlıysa ve birbirleri tarafından değişiklik yapılması gerekiyorsa, ya aynı özellik dalında geliştirmeyi ya da özelliklerin düzenli olarak kodun kararlı bölümlerini ana hat ile birleştirmesini ve ardından değişiklikleri yenilemesini gerektirmeyi düşünebilirsiniz. gövde dalları arasında kod alışverişi yapmak için gövde. Ya da bu iki özelliği diğerlerinden ayırmanız gerekirse, bu özellik dallarını ayırdığınız ve özellikler arasında kod alışverişi yapmak için kullanabileceğiniz ortak bir dal oluşturabilirsiniz.

Yukarıdaki model, 50 geliştirici ve kaynak kontrol sistemi altındaki ekipler için seyrek şubeler ve CVS veya SVN gibi uygun birleştirme kabiliyeti olmayan ekipler için pek mantıklı değil, bu da tüm bu modeli kurulum, yönetme ve entegre etme için bir kabusa çevirir.


5
50 geliştiricinin altındaki takımlar için tarif ettiğiniz şeyin mantıklı olmadığına katılıp katılmadığımdan emin değilim. Çok daha küçük takımlar için de fayda görebiliyorum. +1
Aardvark

2
Elbette, her büyüklükteki ekip için faydalar vardır. Soru, hangi takım boyutunda faydaların ağır bir süreçle ilişkili maliyetlerden daha ağır bastığıdır.
Jiri Klouda

Bu, GitFlow ve / veya GitHubFlow modeline benzer. Bu modellerin Sürekli Entegrasyonu (CI) kolaylaştırdığını sanmıyorum. Bence Trunk Tabanlı Geliştirme bu modellerde önemli bir gelişme.
Yani

Bu yorumun aslında git akışının orijinal sürümünden öncesine dayandığını görebilirsiniz. "Daha iyi" ile ne demek istediğinden tam emin değilim. Bir dereceye kadar entegre edilmiş projeler üzerinde çalışan 1, 5, 25, 150, 1.000 ve 20.000 geliştiriciden oluşan ekipleri destekledim. Gereksinimler değişiklik gösterir ve "daha iyi" çok göreceli bir terimdir. Hiç backport koduna ihtiyacınız var mı? Güvenlik düzeltmeleri? Değilse, hayatınız basittir. SaaS, ana hat tabanlı geliştirmenin getirdiği kısıtlamaların doğrudan bir sonucudur. Özellik bayrakları, özellik dalları kadar karmaşıktır. Sadece müşterilerden onların permütasyonunun bozulduğunu öğrenmeniz dışında.
Jiri Klouda

9

Şahsen ben istikrarlı bir gövdeye sahip olmayı ve dallanma özelliği yapmayı çok daha temiz buluyorum. Bu şekilde, test uzmanları ve benzerleri tek bir "sürümde" kalır ve kod tamamlanmış herhangi bir özelliği test etmek için ana hattan güncelleme yapar.

Ayrıca, birden fazla geliştirici farklı özellikler üzerinde çalışıyorsa, hepsinin kendi ayrı dalları olabilir, ardından işlerini bitirince ana hat ile birleşebilir ve test edenin farklı özellikleri test etmek için birden çok dala geçmesine gerek kalmadan test edilecek bir özelliği gönderebilir.

Ek bir bonus olarak, otomatik olarak gelen bir düzeyde entegrasyon testi vardır.


Ayrıca, her büyük sürüm için hala dallanma ve etiketleme yapıyor musunuz? Yoksa sadece etiket mi?
KingNestor

1
Özellik dalları, bozuk yapılara sahip olmamak için bazı disiplinlerle gövdeye birleştirildiği sürece CI ile iyi çalışır. Her üretim sürümü için yalnızca hata düzeltme için kullanılacak dal ve etiketleme yapıyorum. Bu, ahır gövdesine hemen birleştirilebilir.
Adnan

@king Bunun büyük olasılıkla ana sürüm olarak adlandırdığınız şeye bağlı olduğunu söyleyebilirim, ancak her iki durumda da etiketleyebilir ve ihtiyacınız olduğunda daha sonra dallara ayırabilirsiniz (etikete göre :))
eglasius

5

Her geliştiricinin her gün ana hatta / ana hatta taahhüt ettiği temel ilkelerden birini hatırlamanız koşuluyla, her iki strateji de sürekli geliştirme ile kullanılabilir.

http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay

DÜZENLE

Bu kitabı biraz okudum CI hakkında ve yazarlar, yayınlayarak dallanmanın tercih ettikleri dallanma stratejisi olduğunu öne sürüyorlar. Katılıyorum. CI kullanırken özelliğe göre dallanma bana mantıklı gelmiyor.

Neden bu şekilde düşündüğümü açıklamaya çalışacağım. Diyelim ki üç geliştiricinin her biri bir özellik üzerinde çalışmak için bir dal aldı. Her özelliğin tamamlanması birkaç gün veya hafta sürecektir. Ekibin sürekli entegre olmasını sağlamak için günde en az bir kez ana şubeye taahhüt vermeleri gerekir. Bunu yapmaya başlar başlamaz, bir özellik dalı oluşturma avantajını kaybederler. Değişiklikleri artık diğer geliştiricinin tüm değişikliklerinden ayrı değil. Bu durumda, neden ilk etapta özellik dalları oluşturmaya çalışalım?

Sürüme göre dallanmanın kullanılması, dallar arasında çok daha az birleştirme gerektirir (her zaman iyi bir şeydir), tüm değişikliklerin en kısa sürede entegre olmasını sağlar ve (doğru yapılırsa) kod tabanınızın her zaman yayınlanmaya hazır olmasını sağlar. Serbest bırakarak dallanmanın olumsuz tarafı, değişikliklere çok daha dikkatli olmanız gerektiğidir. Örneğin, büyük çaplı yeniden düzenleme aşamalı olarak yapılmalıdır ve bir sonraki sürümde istemediğiniz yeni bir özelliği zaten entegre ettiyseniz, bir tür özellik değiştirme mekanizması kullanılarak gizlenmelidir .

BAŞKA BİR DÜZENLEME

Bu konuda birden fazla görüş var. İşte CI ile profesyonel özelliklerin dallanması olan bir blog yazısı

http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/


ilginç, bu gönderiyi artık bulamıyorum.
Jirong Hu

5

Yayın dalları çok kullanışlıdır ve hatta uygulamanızın birkaç sürümünü korumanız gerekiyorsa kesinlikle gereklidir.

Özellik dalları da çok kullanışlıdır, özellikle bir geliştiricinin büyük bir değişiklik üzerinde çalışması gerekirken, diğerleri hala yeni sürümler yayınlar.

Bu yüzden her iki mekanizmayı da kullanmak benim için çok iyi bir strateji.

SVN Kitabından ilginç bir bağlantı .


4

Son zamanlarda git kullanırken bu modeli beğenmeye başladım . Sorunuz "svn" olarak etiketlenmiş olsa da, yine de onu biraz kullanabilirsiniz.

Sürekli Entegrasyon bir dereceye kadar bu modeldeki "geliştirme" dalında (ya da her ne derseniz deyin) gerçekleşebilir, ancak gelecekteki sürümler için uzun süreli özellik dallarına sahip olmak, bir yerde kodda meydana gelen her değişikliği düşünmeyi o kadar katı yapmaz. Bunu gerçekten isteyip istemediğiniz sorusu kalır. Martin Fowler yapar.


2

Sürekli entegrasyon, dallanma stratejinizi belirlemede herhangi bir faktör olmamalıdır. Dallanma yaklaşımınız ekibinize, geliştirilmekte olan sisteme ve kullanabileceğiniz araçlara göre seçilmelidir.

Bunu söyledikten sonra ...

  • Tanımladığınız yaklaşımların her ikisinde de CI'nın kullanılmaması için hiçbir neden yok
  • bu yaklaşımlar kombinasyon halinde oldukça iyi çalışıyor
  • ikisi de diğerinden "daha iyi" çalışmıyor
  • CI dengesiz bir gövde ile tamamen mantıklı

Tüm bunlar, diyagramları aldığınız sayfadaki dördüncü soruda yanıtlandı: http://blogs.collab.net/subversion/2007/11/branching-strat/


2

İlkeleri anladığınız sürece, her zaman en iyi uygulamaları yeniden keşfedebilirsiniz. İlkeleri anlamıyorsanız, en iyi uygulamalar, bazı çelişkili dış gereksinimler nedeniyle dağılmadan önce sizi o kadar ileri götürür.

Ana Hat Modeline en iyi giriş için şunu okuyun: https://web.archive.org/web/20120304070315/http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Bağlantıyı okuyun. Temel bilgileri edindikten sonra saygıdeğer Henrik Kniberg tarafından yazılan aşağıdaki makaleyi okuyun. Mainline Modelini sürekli entegrasyonla ilişkilendirmenize yardımcı olacaktır.

http://www.infoq.com/articles/agile-version-control


O'Reilly bölümüne artık erişilemiyor
Jason S

1

Ekibimize başladığımızda, sorumluluğu üstlenmek üzere olduğumuz sistemi orijinal olarak geliştiren tedarikçiden sürüm temelli bir strateji miras aldık. Müşterilerimizin birkaç gelişmiş özelliğin bir sürüme dahil edilmemesini talep ettiği zamana kadar çalıştı (fyi ~ 250 bin kod satırı, ~ 2500 dosya, XP SDLC ile Scrum).

Sonra özellik tabanlı şubelere bakmaya başladık. Bu da bir süre işe yaradı - regresyon testi sürecimizin 2 haftadan fazla süreceğini fark ettiğimiz ana kadar 2 ay gibi, neyin serbest bırakılacağının belirsizliği ile birlikte büyük bir rahatsızlık yarattı.

Saf SC stratejilerinin son "tabutundaki çivi", 1. kararlı gövdeye ve 2. Üretim ST, UAT ve Regresyon testli BINARIES içermelidir (sadece kaynak değil - CC'yi düşünün.)

Bu, bizi, özellik ve yayın tabanlı SC stratejileri arasında melez bir strateji geliştirmeye yönlendiriyor.

Yani bir bagajımız var. Sprint dalını dallandırdığımız her sprint (çevik olmayan insanlar için - bir sprint, karmaşıklığa dayalı değişken çıktılara sahip zaman kutulu bir geliştirme çabasıdır.) Sprint dalından özellik dallarını yaratırız ve bunlarda paralel geliştirme başlar. Özellikler tamamlandığında ve sistem test edildiğinde ve bunları dağıtma niyetini aldığımızda, bunlar sprint dalında birleştirilir - bazıları genellikle daha karmaşık olan birkaç sprint boyunca yüzebilir. Sprint sonuna yaklaştığında ve özellikler tamamlandığında ... sprint dalını "regresyon" olarak "yeniden adlandırıyoruz" (bu, CruiseControl'ün onu herhangi bir yeniden yapılandırma olmadan almasına izin veriyor) ve ardından cc-inşa üzerinde regresyon / entegrasyon testi başlıyor KULAK. Hepsi bittiğinde üretime giriyor.

Kısacası, özellik tabanlı dallar geliştirmek, sistem testi ve UAT işlevselliği için kullanılır. Sprint dalı (gerçekten sürüm dalı), özellikleri isteğe bağlı ve entegrasyon testi ile seçici olarak birleştirmek için kullanılır.

Şimdi burada topluluğa bir soru var - geliştirmenin birçok dalda gerçekleşmesi ve CruiseControl'ün yeniden yapılandırma ek yükünden dolayı sürekli entegrasyon gerçekleştirmede açıkça sorun yaşıyoruz. Birisi önerebilir ve tavsiye edebilir mi?


Sonuçlara kesinlikle katılmıyorum, ancak sürecinizi tartıştığınız için teşekkürler. Herkese uyan tek bir çözüm yoktur.
RaoulRubin

0

Benim gördüğüm kadarıyla odaklanabileceğiniz sınırlı bir dal kümesine sahip olmak istiyorsunuz. Testler, kod kalitesi ölçütleri ve yapılarla birlikte çalıştırmak için birçok ilginç şey istediğinizden, çok fazla rapora sahip olmak muhtemelen bilgileri kaçırmanıza neden olacaktır.

Ne zaman ve neyin dallanacağı, genellikle ekibin büyüklüğüne ve geliştirilmekte olan özelliklerin boyutuna bağlıdır. Altın bir kural olduğunu sanmıyorum. Erken / sık geri bildirim alabileceğiniz bir strateji kullandığınızdan emin olun ve buna, özelliklerin en başından itibaren kaliteyi dahil edin. Kalite biti, takım geliştikçe otomatikleşirken, bir takımın inşa ettiği büyük bir özellik kümesi için dallarsanız, takımda da kaliteye sahip olmanız gerektiği anlamına gelir.

ps Bu yaklaşım referanslarını nereden aldınız? - bu grafiklerin tüm seçenekleri temsil ettiğini düşünmüyor

Güncelleme 1: Bunun altın bir kural olmadığını neden söylediğimi açıklıyor. Temel olarak, nispeten küçük ekipler için bunu en iyi karma bir yaklaşım kullanarak buldum. Özellik dalları, uzun bir şeyse oluşturulur ve ekibin bir kısmı daha küçük özellikler eklemeye devam eder.


Biraz daha var. Ancak Özellik Dalları ve Yayın Dallarının en yaygın 2 tanesi olduğunu düşünüyorum.
KingNestor

0

Continuous Delivery kitabının yazarı Dave Farley , Trunk Based Development'tan (TBD) Continuous Integration (CI) ve Continuous Delivery'nin (CD) temel taşı olarak bahsetti . Diyor:

Herhangi bir dallanma biçimi Sürekli Entegrasyona aykırıdır.

Ayrıca şöyle diyor:

Özellik Dallanma, bireysel bir geliştiricinin bakış açısından çok güzel ancak bir takım açısından yetersizdir. Hepimiz, herkesin ne yaptığını görmezden gelmek ve işimize devam etmek isteriz. Maalesef kod öyle değil. Kaygıların güzel bir şekilde ayrıldığı ve harika bir şekilde gevşek bağlı bileşenlere sahip çok iyi faktörlü kod tabanlarında bile, bazı değişiklikler sistemin diğer bölümlerini etkiler.

Trunk Tabanlı Geliştirme (TBD) , kod değişikliklerini ana hat (diğer bir deyişle ana hat) içine en az günde bir kez - tercihen günde birden çok kez entegre etme uygulamasıdır. Sürekli Entegrasyon (CI), otomatik testler kullanılarak kod değişikliklerinin doğrulanmasını içermesi dışında benzer bir uygulamadır. Bunun için en iyi dallanma stratejisi, doğrudan ana hat dışında çalışmak ve Eş Programlama yoluyla kod incelemeleri yapmaktır . Herhangi bir nedenle eşleştiremiyorsanız veya gerçekten dallanmak istiyorsanız, dallarınızın kısa ömürlü olduğundan (bir günden az) emin olun.

GIT depolarımda Trunk, "master" üzerinde çalışıyorum. Yerel olarak ustalaşmayı ve ağa bağlandığımda hemen CI'ın çalıştığı merkezi ana depoma göndermeyi taahhüt ediyorum. Bu kadar!

Büyük özellikler için (yani bir günden uzun süren özellikler), bunları, yazılımı kırmadan ana hat içine entegre edilebilen küçük mantık parçalarına ayırmaya çalışın. Son kullanıcıları etkilemeden tamamlanmamış çalışmaları dağıtmanıza olanak tanıyan , soyutlama yoluyla özellik işaretleme ve dallanma gibi teknikleri de kullanabilirsiniz .

Dalları soyutlama, karanlık bırakma ve bazen özellik bayrakları ile kullanıyorum. Karşılığında aldığım şey hızlı, kesin (en azından testimin kalitesine göre) geri bildirim.


Dave Farley ve Jez Humble dallanma konusundaki tutumlarında tamamen yanılıyorlar. Bunun nedeni, önemli bir varsayımı kodlamasıdır: "kodu özellik düzeyinde hiçbir zaman manipüle etmek zorunda kalmayacaksınız ve eğer, bu durumda pahalı işlem olabilir" ve değerlendirmelerini başka bir varsayıma dayandırıyorlar "birleştirme, otomatikleştirilmiş ile çok pahalı büyük ölçekte neredeyse imkansız hale geliyor ". Bu iki varsayım doğru değilse, birleştirmenin ucuz olduğu bir dünyada yaşıyorsanız, ancak arka bağlantı noktaları ve güvenlik düzeltmeleri için özellik düzeyinde kodu değiştirmeniz gerekiyorsa, ifadeleri bozulur. Bu nadir bir durum tho.
Jiri Klouda

Bazı şirketlerin, bu özellikler uygulamada engellere ulaştıktan ve bir sürümü beklettikten sonra, özellikleri gelecekteki sürümlere taşıması gerekir. Bazen SaaS ürünlerinde olduğu gibi kodu içeride bırakma seçeneği vardır, ancak kod müşterilere yayınlanırsa, rakipler tarafından analiz edilebileceği için bir seçenek olmayabilir. Bugünlerde çok fazla kod derlenmiyor ve öyle olsa bile, koddaki tanımlar / özellik bayrakları dallarla aynı karmaşıklık seviyesindedir.
Jiri Klouda

-3

Bence kullandığınız araçlar burada büyük bir faktör.

  • Devirme kullanıyorsanız, seçenek 1'e bağlı kalın ve dallardan kurtulun.
  • GIT kullanıyorsanız, 2. seçenek sizin için iyi çalışacaktır.

2
Özellik dallarına herhangi bir SCM ile kolayca ulaşılabilir
hdost
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.