Bir dalda veya bagajda gelişmeye devam ediyor musunuz? [kapalı]

Periyodik sürümleri olan bir yazılım ürünü geliştirdiğinizi varsayalım. Dallanma ve birleştirme ile ilgili en iyi uygulamalar nelerdir? Periyodik serbest bırakma dallarını halka (veya müşterinizin olduğu her kim olursa olsun) dilimlemek ve daha sonra gövdede gelişmeye devam etmek veya gövdeyi kararlı versiyonu düşünmek, periyodik olarak bir yayın olarak etiketlemek ve dallarda deneysel çalışma yapmak. İnsanlar bagajın "altın" veya "kum kutusu" olarak değerlendirildiğini düşünüyor?

Her iki yöntemi de büyük bir ticari uygulama ile denedim.

Hangi yöntemin daha iyi olduğu yanıtı büyük ölçüde sizin durumunuza bağlıdır, ancak genel deneyimimin şimdiye kadar gösterdiklerini yazacağım.

Genel olarak daha iyi bir yöntem (deneyimlerime göre): Gövde her zaman sabit olmalıdır.

İşte bu yöntemin bazı yönergeleri ve faydaları:

• Her görevi (veya ilgili görev grubunu) kendi dalında kodlayın, bu görevleri ne zaman birleştirmek ve serbest bırakmak istediğinizde esnekliğe sahip olursunuz.
• KG, gövdeye birleştirilmeden önce her dalda yapılmalıdır.
• Her dalda KG yaparak, hatanın neyin daha kolay olduğunu tam olarak bileceksiniz.
• Bu çözüm, herhangi bir sayıda geliştiriciye göre ölçeklendirilir.
• Dallanma SVN'de neredeyse anında yapılan bir işlem olduğundan bu yöntem işe yarar.
• Gerçekleştirdiğiniz her sürümü etiketleyin.
• Bir süredir yayınlamayı planlamadığınız özellikleri geliştirebilir ve bunları ne zaman birleştireceğinize tam olarak karar verebilirsiniz.
• Yaptığınız tüm işler için kodunuzu yerine getirme avantajına sahip olabilirsiniz. Yalnızca bagajdan çıkarsanız, muhtemelen kodunuzu çok fazla taahhütte bulunmayacaksınız ve dolayısıyla korumasız ve otomatik geçmiş olmadan.

Eğer tersini yapmaya çalışır ve bagajdaki tüm gelişiminizi yaparsanız, aşağıdaki sorunlara sahip olacaksınız:

• Günlük yapılar için sürekli inşa problemleri
• Bir geliştirici projedeki diğer tüm insanlar için bir sorun üstlendiğinde verimlilik kaybı
• Daha uzun yayın döngüleri, çünkü nihayet kararlı bir versiyona ihtiyacınız var
• Daha az kararlı sürüm

Bir dalın sabit kalmasını ve gövdeyi geliştirme sanal alanı olarak tutmaya çalışırsanız ihtiyacınız olan esnekliğe sahip olmayacaksınız. Bunun nedeni, bu kararlı sürümde ne koymak istediğinizi bagajdan seçip seçememenizdir. Her şey bagajda birlikte karışık olurdu.

Özellikle gövdedeki tüm gelişmeleri yapmak istediğimi söyleyeceğim tek durum, yeni bir projeye başladığınız zamandır. Durumunuza bağlı olarak başka durumlar da olabilir.

Bu arada dağıtılmış sürüm kontrol sistemleri çok daha fazla esneklik sağlar ve hg veya git'e geçmenizi şiddetle tavsiye ederim.

Her iki teknikle de çalıştım ve gövdede gelişmenin ve sürümler olarak istikrarlı noktaların dallanmasının en iyi yol olduğunu söyleyebilirim.

Üzerinde sahip olacağınızı söyleyenlere itiraz edenler:

• Günlük yapılar için sürekli inşa problemleri
• Bir geliştirici projedeki diğer tüm insanlar için bir sorun üstlendiğinde verimlilik kaybı

muhtemelen sürekli entegrasyon tekniklerini kullanmamışlardır.

Gün içinde birkaç test yapmazsanız, her saat başı bir kez söyleyin, kendilerini gelişme hızını hızla boğacak olan bu sorunlara açık bırakacaksınız.

Gün boyunca birkaç test derlemesi yapmak, ana kod tabanındaki güncellemeleri hızlı bir şekilde katlar, böylece başkaları onu kullanabilir ve ayrıca bir kişi binayı bozarsa gün içinde sizi uyarır, böylece eve gitmeden önce düzeltebilir.

Belirtildiği gibi, sadece regresyon testlerini yürütmek için gece yapımı başarısız olduğunda kırık bir yapı hakkında bilgi edinmek saf bir ahmaktır ve işleri yavaşlatır.

Martin Fowler'in Sürekli Entegrasyon hakkındaki makalesini okuyun . Büyük bir proje (3.000kSLOC) için kendi sistemimizi yaklaşık 2.000 satır Posix sh'de yuvarladık.

"Serbest bırakma dalı" yaklaşımını benimseme eğilimindeyim. Gövde uçucudur. Serbest bırakma zamanı yaklaştığında, daha dikkatli davranacağım bir serbest bırakma dalı yapardım. Sonunda bittiğinde, deponun durumunu etiketler / etiketlerdim, böylece "resmi" yayınlanan sürümü bilirdim.

Bunu yapmanın başka yolları olduğunu anlıyorum - geçmişte yaptığım gibi.

Her ikisi de.

Gövde, gelişimin çoğunluğu için kullanılır. Ancak, bagajda herhangi bir check-in'in kırılmamasını sağlamak için en iyi çabaların gösterilmesi beklenmektedir. (otomatik bir derleme ve test sistemi tarafından kısmen doğrulanmıştır)

Sürümler kendi dizinlerinde tutulur, yalnızca hata düzeltmeleri yapılır (ve daha sonra bagajda birleştirilir).

Bagajı dengesiz veya çalışmayan bir durumda bırakacak herhangi bir yeni özellik kendi ayrı dalında yapılır ve daha sonra tamamlandıktan sonra bagajda birleştirilir.

Henrik Kniberg'in Çoklu Çevik Takımlar için Versiyon Kontrolünde tarif ettiği yaklaşımı seviyorum ve kullanıyorum . Henrik , birden fazla ekiple (geleneksel ortamlarda tek bir ekip için de çalışır) çevik bir ortamda sürüm kontrolünün nasıl ele alınacağını açıklamakta harika bir iş çıkardı ve onu başka bir şekilde ifade etmenin bir anlamı yok, bu yüzden sadece "hile sayfasını" ( aşağıda açıklanmaktadır):

Beğendim çünkü:

• Çok basit: Resimden alabilirsiniz.
• Çok fazla birleştirme ve çatışma sorunu yaşamadan iyi çalışır (ve ölçeklendirir).
• İstediğiniz zaman (çeviklik ruhu içinde) "çalışan yazılım" yayınlayabilirsiniz.

Ve yeterince açık olmaması durumunda: "çalışma dal (lar) ında" geliştirme yapılırsa, gövde DONE (serbest bırakılabilir) kodu için kullanılır. Kontrol Çoklu Çevik Ekipleri için Sürüm Kontrolü tüm ayrıntılar için.

Gövdesini sabit tutan ve tüm şubelerde çalışan bir geliştirme sürecine iyi bir referans Divmod'un Nihai Kalite Geliştirme Sistemidir . Kısa bir özet:

• Yapılan tüm işlerin kendisiyle ilişkili bir bileti olmalıdır
• Bilet için çalışmanın yapıldığı her bilet için yeni bir şube oluşturulur
• Bu şubedeki değişiklikler, başka bir proje üyesi tarafından incelenmeden ana hat bagajında ​​birleştirilmez.

Bunun için SVN kullanıyorlar, ancak bu, dağıtılmış sürüm kontrol sistemlerinden herhangi biriyle kolayca yapılabilir.

Sanırım ikinci yaklaşımınız (ör. Yayınları etiketlemek ve dallarda deneysel şeyler yapmak, gövdenin kararlı olduğunu düşünmek) en iyi yaklaşımdır.

Dalların, bir sistemin tüm hatalarını, dallandığı zaman diliminde miras aldığı açıktır: bir gövdeye düzeltmeler uygulanırsa, dalları bir çeşit olarak tutarsanız, tüm dallara tek tek gitmeniz gerekecektir. serbest bırakma döngüsü sonlandırıcı. Zaten 20 sürümünüz varsa ve birincisine kadar geri giden bir hata keşfettiyseniz, düzeltmenizi 20 kez yeniden uygulamanız gerekir.

Dalların gerçek kum kutuları olması gerekiyordu, ancak gövde de bu rolü oynamak zorunda kalacak: etiketler, kodun o anda "altın" olup olmadığını, serbest bırakılmaya uygun olduğunu gösterecektir.

Değişiklikler çok büyük olmadıkça, dengesizleşmedikçe veya ürünlerimizden birinin büyük bir sürümüne yaklaşmadığımız takdirde gövde üzerinde gelişiriz, bu durumda geçici bir şube oluştururuz. Ayrıca, her bir ürün sürümü için kalıcı bir şube oluşturuyoruz. Microsoft'un Dallanma Kılavuzu belgesini oldukça yararlı buldum . Eric Sink'in dallanma eğitimi de ilginç ve Microsoft için işe yarayanların geri kalanımız için çok ağır olabileceğine dikkat çekiyor. Bizim durumumuzda, aslında Eric'in ekibinin yaptığı yaklaşımı kullanıyoruz.

Bu sizin durumunuza bağlıdır. Perforce kullanıyoruz ve tipik olarak birkaç geliştirme çizgisine sahibiz. Gövde "altın" olarak kabul edilir ve bütün gelişim, entegre olacak kadar kararlı olduklarında ana hatta geri dönen dallarda gerçekleşir. Bu, kesim yapmayan ve zaman içinde bağımsız projelerin / özelliklerin alabileceği sağlam artım kabiliyeti sağlayabilen özelliklerin reddedilmesine izin verir.

Bagajın içine yuvarlanan yeni özellikleri birleştirme ve yakalama için entegrasyon maliyeti var, ancak yine de bu acıyı çekeceksiniz. Herkesin gövdede birlikte gelişmesi vahşi batı durumuna yol açabilirken, dallanma acı entegrasyon haplarını almak istediğiniz noktaları ölçeklendirmenize ve seçmenize izin verir. Şu anda bir düzine projede yüzün üzerinde geliştiriciye ölçekliyiz, her biri aynı çekirdek bileşenleri kullanan birden fazla sürüm var ve oldukça iyi çalışıyor.

Bunun güzelliği, bunu tekrar tekrar yapabilmenizdir: büyük bir özellik dalı, eğer varsa diğer dallarla birlikte kendi gövdesi olabilir. Ayrıca, son sürümler size istikrarlı bakım yapmak için bir yer vermek için yeni bir şube alır.

Mevcut üretim kodunun bakımını yeni gelişme doğrultusunda yönetmeye çalışmak en iyi ihtimalle sorunludur. Bu sorunları azaltmak için, test çalışmaları tamamlandığında ve kod teslime hazır olduğunda kodun bir bakım hattına dalması gerekir. Ek olarak, ana hat, salım stabilizasyonuna yardımcı olmak, deneysel geliştirme çabalarını içermek veya yaşam döngüsü birden fazla salım boyunca uzanan geliştirme çabalarını barındırmak için dallanmalıdır.

Bakım gerektirmeyen bir şube, yalnızca kod arasında başka bir şekilde yönetilmesi zor olan çarpışma olasılığı (veya kesinliği) olduğunda oluşturulmalıdır. Şube lojistik bir problemi çözmezse, bir problem yaratacaktır.

Ana çizgide normal salım gelişimi meydana gelir. Geliştiriciler normal serbest bırakma işi için ana hatta girip çıkıyor. Mevcut Üretim koduna yönelik yamalar için geliştirme çalışmaları, bu sürümün şubesinde olmalı ve yama testten geçip dağıtıldıktan sonra ana hat ile birleştirilmelidir. Bakım gerektirmeyen branşlardaki çalışmalar duruma göre koordine edilmelidir.

Geliştirme çabanızın boyutuna bağlıdır. Paralel çalışan birden fazla ekip aynı kodda (gövde) etkili bir şekilde çalışamaz. Sadece küçük bir grup çalışanınız varsa ve asıl endişeniz bir dalı kesiyorsa, işe yarayacak mevcut üretim koduna hata düzeltmeleri yapmak için şubeye geri dönerken çalışmaya devam edebilirsiniz. Bu önemsiz bir dallanma kullanımıdır ve çok külfetli değildir.

Çok sayıda paralel gelişiminiz varsa, çabaların her biri için şubeler olmasını isteyeceksiniz, ancak bu da daha fazla disiplin gerektirecektir: Şubelerinizin test edildiğinden ve birleştirilmeye hazır olduğundan emin olun. İki grubun aynı anda birleşmeye çalışmaması için birleştirme zamanlama.

Bazı dallar o kadar uzun bir süredir geliştirilmektedir ki, son olarak gövdeye geri dönerken sürpriz sayısını azaltmak için gövdeden şubeye birleşmelere izin vermelisiniz.

Çok sayıda geliştiriciniz varsa denemeniz ve durumunuzda neyin işe yaradığına dair bir fikir edinmeniz gerekecektir. İşte Microsoft'tan biraz faydalı olabilecek bir sayfa: http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

Ana geliştirme için bagajı ve bültenlerin bakım çalışmaları için şube kullanıyoruz. Güzel çalışıyor. Ancak dallar yalnızca hata düzeltmeleri için kullanılmalıdır, özellikle veritabanı tarafında büyük değişiklikler yapılmamalıdır, ana gövdede yalnızca bir şema değişikliğinin gerçekleşebileceği ve hiçbir zaman şubede bulunamayacağı kuralı vardır.

Eğer bir serbest bırakma döngüsü, büyük bir özellik üzerinde çalışacaksanız, bir dalda bordo. Aksi takdirde, bagajda çalışıyoruz ve inşa ettiğimiz her üretim sürümü için şube yapıyoruz.

Önceki üretim yapıları o sırada old_production_'a taşınır ve mevcut ürün sürümü her zaman sadece üretimdir. Yapım sunucumuzun üretim hakkında bildiği tek şey, üretim dalının nasıl konuşlandırılacağıdır ve bu yapıyı bir kuvvet tetikleyicisi ile başlatırız.

Trunk = güncel gelişim akışı, şube = sürüm (ler) yaklaşımını takip ediyoruz. Müşteriye salıverildikten sonra bagajı kollara ayırırız ve bagajı ileriye doğru hareket ettiririz. Kaç sürümü desteklemeye hazır olduğunuza karar vermeniz gerekecektir. Ne kadar çok destek verirseniz, hata düzeltmelerinde o kadar çok birleşme gerçekleştireceksiniz. Müşterilerimizi bagajın arkasında en fazla 2 sürümde tutmaya çalışıyoruz. (Örn. Dev = 1.3, desteklenen sürüm 1.2 ve 1.1).

Gövde genellikle ana geliştirme hattıdır.

Bültenler dallara ayrılır ve genellikle dallar üzerinde deneysel veya büyük çalışmalar yapılır ve daha sonra ana geliştirme hattına entegre edilmeye hazır olduğunda gövdeye geri döner.

Gövde genellikle ana geliştirme kaynağınız olmalıdır. Aksi takdirde, yeni özelliklerde birleştirmek için çok zaman harcayacaksınız. Başka bir şekilde yapıldığını gördüm ve genellikle son dakika entegrasyon baş ağrılarına yol açar.

Aktif gelişmeleri dağıtmadan üretim acil durumlarına hızlı bir şekilde yanıt verebilmemiz için bültenlerimizi etiketliyoruz.

Benim için kullandığım yazılıma bağlı.

CVS altında, sadece "gövde" çalışmak ve asla etiket / şube, çünkü aksi takdirde gerçekten acı vericiydi.

SVN, ben "kanayan kenar" şeyler bagajda yapardı, ama bir sunucu itme zamanı geldiğinde uygun şekilde etiketlenmiş olsun.

Geçenlerde git'e geçiyorum. Şimdi asla bagajda çalışmadığımı görüyorum. Bunun yerine "new-featurename" adlı bir sanal alan dalı kullanıyorum ve daha sonra sabit bir "geçerli üretim" dalıyla birleşiyorum. Şimdi düşündüğüme göre, "güncel üretim" e geri dönmeden önce gerçekten "release-VERSIONNUMBER" dalları yapmalıyım, böylece eski kararlı sürümlere geri dönebilirim ...

Bu gerçekten kuruluşunuzun / ekibinizin sürümleri ne kadar iyi yönettiğine ve hangi SCM'yi kullandığınıza bağlıdır.

• Bir sonraki adım (bir sonraki sürümde) kolayca planlanabiliyorsa, bagajda gelişmek daha iyidir. Şubeleri yönetmek daha fazla zaman ve kaynak gerektirir. Ancak bir sonraki aşama kolayca planlanamazsa (büyük organizasyonlarda her zaman olur), muhtemelen şubelerden (birkaç veya on) ziyade kiraz toplama taahhütlerine (yüzlerce / binlerce) ulaşırsınız.
• Git veya Mercurial ile şubeleri yönetmek cvs ve yıkımdan çok daha kolaydır. Sabit gövde / konu dalları metodolojisine giderdim. Git.git ekibi bunu kullanıyor. okuyun: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• Subversion ile ilk önce bagajda geliştirme metodolojisini uyguladım. Çıkış tarihi geldiğinde oldukça fazla iş vardı çünkü her zaman taahhütleri almak zorunda kaldım (şirketim planlamada iyi değil). Şimdi Subversion konusunda uzmanım ve Subversion'daki şubeleri yönetmeyi çok iyi biliyorum, bu yüzden istikrarlı gövde / konu dalları metodolojisine doğru ilerliyorum. Eskisinden çok daha iyi çalışıyor. Muhtemelen Subversion'a sadık kalalım, şimdi git.git ekibinin nasıl çalıştığını deniyorum.

İşte tercih ettiğim SVN tasarımı:

• kök
  • gelişme
    • dalları
      • Feature1
      • feature2
      • ...
    • gövde
  • beta
    • etiketler
    • gövde
  • serbest bırakmak
    • etiketler
    • gövde

Kendi şubesini gerektiren ana özellikler hariç, tüm çalışmalar geliştirme / bagajdan yapılır. İş geliştirme / gövdeye karşı test edildikten sonra, test edilen sorunları beta / gövdeye birleştiriyoruz. Gerekirse, kod beta sunucusuna karşı test edilir. Bazı değişiklikleri kullanıma hazır hale getirmeye hazır olduğumuzda, uygun düzeltmeleri serbest bırakma / devre ve dağıtma ile birleştiririz.

Etiketler hem beta hem de sürüm dalında yapılabilir, böylece hem beta hem de sürüm için belirli sürümleri takip edebiliriz.

Bu tasarım çok fazla esneklik sağlar. Ayrıca, bazı revizyonlar beta testlerini geçmediyse, başkalarını serbest bırakıp / trunkla birleştirmek için birleştirirken, beta / trunk'ta revizyon bırakmamızı kolaylaştırır.

Kullandığımız yöntem Laura Wingerd'in harika kitabında uzunca tartışılan Performans yaklaşımıdır:

http://oreilly.com/catalog/9780596101855/index.html

Kitap performans merkezli olsa da (Wingerd bir Perforce ürün yöneticisidir), kavramlar VCS'nin herhangi birine veya tümüne uygulanabilir.

Performans yaklaşımı (ve platform) bize çok iyi hizmet etti. Birçok firmada kullanılır (google, Intuit ve duydum ki Microsoft Windows'un kendisi).

Kitap iyi okumaya değer.

Bunu okuyun: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Yıkım konvansiyonu sorusu IMHO için herkese uyan tek bir cevap yok.

Bu gerçekten projenin ve onu kullanan şirketin dinamiklerine bağlıdır. Çok hızlı bir ortamda, her birkaç günde bir sıklıkta bir sürüm olabileceği zaman, dini olarak etiketlemeye ve dallamaya çalışırsanız, yönetilemez bir depoya sahip olursunuz. Böyle bir ortamda, ihtiyaç duyulduğunda şube yaklaşımı çok daha sürdürülebilir bir ortam yaratacaktır.

Ayrıca - deneyimlerime göre, saf bir yönetim açısından, seçtiğinizde svn metodolojileri arasında geçiş yapmak son derece kolaydır.

En iyi çalıştığını bildiğim iki yaklaşım, ihtiyaç duyulduğunda branş ve her görev branşındadır. Bunlar tabii ki birbirinin tam tersidir. Dediğim gibi - hepsi proje dinamikleriyle ilgili.

@Brian R. Bondy: Ekibiniz projeye paralel olarak ele alınan belirli bir miktar değere / göreve ulaştığında bunun bir çözüm olmadığını lütfen unutmayın.

KG departmanı qa'ya katıldıktan sonra, devam eden şube başına bir kurulum sağlamak için gereken çabalar çok fazladır. Her biri şube başına sağlanması gereken SOA / İstemciler / Sunucular / Web Servisleri / Veritabanlarını düşünün .

Bu çözüm, entegrasyon aşamasından da yoksundur.