Sürümler için doğru dallanma stratejisini seçme

Yeni bir projede yeni bir geliştirme ekibi ile başlayarak kaynak havuzumuz için Dallanma stratejimizi tanımlamamız gerekiyor ( örn. Microsoft Team Foundation Server 2010 ). Yapılıp yapılmayacağı konusunda yapışkan bir tartışmaya girdik ...

Bir . Üretim yapıları yaptığımız bir Sürüm şubesine ve bir şey gerçekten yayınlandığında Etiketle

VEYA

B . Üretime sunulan her yeni Sürüm için yeni bir Sürüm şubesine sahip olun ( Örn. Sürüm 1, 2, 3, vb. )

Seçenek A oldukça basit görünüyor, ancak bunun uzun vadede sorunlara yol açıp açmayacağından emin değiliz. Seçenek B , sadece zaman içinde biriken çok sayıda tek seferlik uzun ömürlü dallar oluşturuyor gibi görünüyor.

Karar vermemize yardımcı olabilecek herhangi bir şekilde herhangi bir tecrübesi olan var mı? Özellikle, ağrı noktalarının herhangi bir seçim için nerede olduğunu duymak istiyorum. TFS ve / veya Release-Management sonuçları ile ilgili olarak belirli bir deneyim sunmaktan çekinmeyin.

Seçenek A. Sadece serbest bırakmak için ana hat ve etiketleme kullanma

Artıları:

• Cehennem birleştirme kaçının.
• Ana çizgiye uymak, uygun serbest bırakma planlaması, çok fazla WIP sunmamak, bant dışı uzun süreli işlerle uğraşmak için soyutlama ile dallanma kullanmak ve açık iş sistemini ve yönetme işleriyle uğraşmak için yapılandırılabilir özellikleri kullanmak gibi bazı en iyi uygulamaları teşvik eder. devam eden; ya da olmayabilir; tam bir geri dönüşü serbest bırakmak veya önlemek için şimdi veya gelecekte devre dışı bırakılması gerekir.

Eksileri:

• Devam eden çalışmalarla uğraşmak bir sorun haline gelir ve serbest bırakılma zamanı geldiğinde potansiyel yüzey saldırı alanına katkıda bulunur. Bununla birlikte, geliştiricileriniz disiplinli ise, yeni özellikler yapılandırılabilir ve modüler olmalı ve bu nedenle kolayca devre dışı bırakılabilir / etkinleştirilebilir veya WIP yoktur ve her sürüm noktasında tüm işler ya tamamlanır ya da henüz başlatılmaz (yani Scrum).
• Büyük ölçekli / bant dışı değişiklikler uygulamak için önceden daha fazla düşünmeyi gerektirir (örn. Soyutlama ile dallanma).

Şahsen ben bu yaklaşımı tercih ediyorum. Kod kapsamı ve birim testleri, kapıdan çıkmaya hazır olmayan kodu tanımlamalı ve insanlar geçerli yineleme sırasında yayınlanmayacak kodlar üzerinde çalışmamalıdır. Soyutlama veya diğer mekanizmalarla dallanma, uzun vadeli değişikliklerle ve devam eden çalışmalarla başa çıkmak için kullanılabilir.

Bunu yapmadığınızda, birleştirme sorunları, eski kod, hiçbir zaman yayınlanmayan özellikler vb.

Seçenek B. Serbest bırakma dalı

Artıları:

• Geçerli yineleme kabul testi tamamlanırken bir sonraki yineleme üzerinde çalışmaya başlayabilirsiniz.
• Diğer şeyler im emin.

Eksileri:

• Tonlarca dal.
• Hala sürüm noktalarında şubeleri etiketlemeniz gerekiyor.
• Hala yapmayacaksa ve yine de serbest bırakma dalını devre dışı bırakması veya çekmesi ve kabul testlerini yeniden çalıştırması gerekiyorsa, WIP ile uğraşmak ve önceki yayın dalından WIP'yi bir sonraki yayın dalına birleştirmek gerekir.
• Düzeltmelerin daha fazla dalda uygulanması gerekir (serbest bırakma dalı + düzeltme + yeni etiket + düzeltmeyi vnext dalına birleştirin ve düzeltmenin nerede olduğuna bağlı olarak muhtemelen vnextnext).

Ben bu çözümün büyük bir hayranı değilim ^ _ ^.

Genellikle sadece ana hatta sadık kalmaya çalışmanızı tavsiye ederim. Geliştiricileriniz, kesim başarısız olduğunda kolayca çekilebilen veya bir sonraki sürüm için erken kontrol edilen WIP yazmama konusunda sorun yaşıyorsa, kodu kodun tamamlanması ve dallanması gereken noktada etiketleme hakkında konuşmaya başlayabilirsiniz. gerektiğinde, geliştiriciler birim testlerinizin yakalayamadığı gözden kaçan hataları ve hataları ele almak için.

İdeal olarak, bunun kural değil, istisna süreci olmasını istediğinizi düşünüyorum.

Seçenek C. Çılgın Bonus Seçeneği

Süslü olmak istiyorsanız, kullanıcı başına hikaye / özellik başına dallanma modelini de düşünebilirsiniz. ( TFS veya DVCS olmayan herhangi bir şey, aynı zamanda git veya mercurial gibi bir DVCS kullanılıyorsa uygulanması son derece önemsizdir ).

Geçmişte, svn'den civaya kolayca taşınamayan eski bir kod tabanı ile çalışan önceki bir işveren bakım ekibi için aşağıdakileri uyguladım. Sadece sürümleri daha iyi koordine etmek yerine, her zaman serbest bırakılabilir bir ana hattın iş gereksinimlerini karşılamak için birçok gereksiz çalışma yapıldı. . .

1. Özellikler, ekipleri dev dalında geliştiriciler tarafından geliştirildi.
2. Bir özellik akran değerlendirilmeye hazır olduğunda, geliştiriciler, Dev dalından CR dalına tek bir birleştirmede birleştirir ve özellik kimliği / kullanıcı hikayesini başlığa ekler. * Ön işleme kancası ile uygulanır *
3. CR'yi geçtikten sonra özelliği KG şubesine yükseltmek için bir yönetici aracı kullanılır. (Çeşitli kabul aşamalarında mevcut olan kullanıcı hikayelerini listeleyen ve operatörün bu kabul aşamaları arasında tanıtmasını veya indirilmesini sağlayan küçük bir terminal uygulaması yazdım)
4. KG otomasyon ve manuel kullanılabilirlik testlerini gerçekleştirir. Özellik iyi ise, serbest bırakma dalına (ana hat) itilir. Özellik reddedilirse, geliştiriciler test sırasında ortaya çıkan sorunları çözene ve CR şubesine bir yama ekleyene kadar KG şubesinden indirgenir / geri döndürülür.
5. Kod KG şubesinden döndürülürse ve bir düzeltme uygulanırsa, terminal aracı, özelliği CR şubesinden KG şubesine geri getirmek için gerekli değişiklikleri yeniden uygular, böylece KG kodu yeniden gözden geçirebilir ve ya tekrar indirgemek.
6. Herhangi bir zamanda salım dalı kararlı bir serbest bırakılabilir durumda olmalıdır.
7. Bir sürümün ardından yeni Dev, QA ve CR ana hattan döndürülür.

Çıkardığımız her sürüm için ayrı şubelerimiz var (yaklaşık 4 yıl). Belirli bir sürümü çıkarmanız gerektiğinde çok uygundur.

Birkaç eski sürüme sahip olmanız gerekiyorsa, etiketlemenin işe yarayacağını sanmıyorum. Belirli sürüm dalları ile, diğer sürümlerden endişe etmeden her bir şubeye ayrı ayrı (veya bunların bir seçimine) hot-fix uygulayabilirsiniz.

Ayrıca, bir hata veya özellik sunulduğunda avlandığınızda sürümleri karşılaştırmayı çok daha kolay hale getirir.

Şube sayısı veya değişiklik yapmadan geçtikleri zaman hakkında endişelenmeyin. Sürüm oluşturma sisteminiz size kontrol sağlamak ve projenizin gelişiminin bir geçmişini sunmaktır. Tarihin değişme eğilimi vardır ... Ve CV'lerinizin baş edememesi konusunda endişelenmeyin. Bir geliştirme dalında Perforce, 9000+ dosya, üzerinde çalıştığımız sürüm (ler) için 50'ye kadar geliştirme dalı ve daha önce de belirttiğimiz gibi, yayınladığımız her sürüm için tek bir şube kullanıyoruz. Performans daha da nefes almıyor.

Kısacası: bir geliştirici / bakımcı / hata giderici / problem avcısı olarak hayatınızı kolaylaştırın ve şube sayısı veya dosya sayısı hakkında endişelenmeyin. Kendine saygılı her cvs başa çıkabilir.

Düzenle:

Sahip olduğumuz şube sayısı konusunda hiç karışıklık yaşamıyoruz. Sürüm şubeleri için adlandırma şemamız ve geliştirme (veya iş) şubeleri için 1 sayı 1 şube politikamızın bununla bir ilgisi olabilir.

Sürüm şubeleri, ellerindeki sürüm için adlandırılır, örneğin: Sürüm 2011 Service Pack 1 için R2011SP1: İş şubelerimizin daha az akıllı adları vardır: alt01, alt02, alt03 vb. "Alt", tüm iş dallarının alt dal olması gerçeğinden gelir. kabul şube. Kabul dalı, serbest bırakılmaya hazır tüm konuların toplandığı şubedir.

1 sayı 1 çalışma kolu politikamız, sayı takip sistemimizin "şube" alanı ile kişiselleştirilmiş olmasıyla birlikte, hangi branşta hangi sorunun geliştirildiğini her zaman bilmemizi sağlar. Kabul dalına bir sorun entegre edildiğinde bu alan güncellenir. Bu, hangi sorunların yayınlanmaya hazır olduğunu her zaman bildiğimiz anlamına gelir (kabul testi yapıldıktan sonra). Benzer şekilde, bir sürüm dalı oluşturulduğunda bu alanı güncelleriz ve bu şekilde, hangi sürümün yayınlandığını her zaman izleyebiliriz.

Her şey bağlamla ilgili: ne sıklıkla serbest bırakıyorsunuz ve ne serbest bırakıyorsunuz.

B yöntemini kullanarak eski çalışmamla yaşadığım bir örnek olay incelemesi (buna amaca göre şube adını verdik ).

Hikayeyi bağlama koymak için,

• Bir sürüm, yazılımımızdaki yeni özelliklerden oluşuyordu: yeni oyun modları, yeni işlevler, yeni yapılandırma seçenekleri.
• Serbest bırakma döngüsü oldukça uzundu: Müşterilerimiz genellikle bir yıl boyunca belirlenen bir özelliğe bağlı kalacak üniversitelerdi.

Belli bir sürüm için tam özellikli bir duruma ulaşıncaya kadar ana gelişme gövdeye yapıldı. Bu noktada, bir şube oluşturacağız, proje adı-ocak2012 diyelim ve o dalda kalite testlerimizi ve hata düzeltmelerimizi yapardık . Herkese açık bir kullanıma hazır olduktan sonra, o daldaki kodu etiketleyip yayınlardık.

Ancak, sürümdeki geliştirme bu etikette sona ermedi. Kaçınılmaz olarak, sürümde hata veya küçük sorunlar bulan müşterilerimiz vardı. Bu durumda, tek yapmamız gereken, o şubeye geri dönmek, kodu yamalamak ve serbest bırakılmak üzere january2012 şubesinin yeni bir etiketli sürümünü oluşturmak ve düzeltmeleri bagajda birleştirmektir.

Bizim durumumuzda, bu yaklaşım olumluydu, çünkü bazı kullanıcılar sınırlı bir dizi özelliğe sahip eski sürümlerle kalmayı tercih ettiler ya da sadece bir düzeltme yerine altyapılarına dağıtmanın maliyeti bazı sorunlara neden oldu.

Kendinize sormanız gereken sorular:

• Ne sıklıkla serbest bırakarım?
• Sürümlerim% 100 geriye dönük uyumlu olacak mı?
• Müşterilerim hataları düzeltmek için tamamen yükseltme ile iyi olacak mı?

Sık sık serbest bırakırsanız, belki de her biri için dallara sahip olmaya değmez. Ancak, sürüm döngünüz eski kullanım durumum gibi oldukça uzunsa ve dağıtım, geriye dönük uyumluluk ve eski sürümlere yapışan müşteriler risk olabilir, B seçeneği kesinlikle sizi çok fazla acıdan kurtarır, işleri desteklemeyi çok daha kolay hale getirir şube karmaşası ile uğraşmak minimum maliyetle müşterileriniz.

Seçenek A'yı tercih ederim. Gövde ve şube bültenleri stabil olduğunda geliştirin. Bu, üretim sürümüne uygulanan düzeltmeleri entegre etme konusundaki çalışmaları önemli ölçüde sınırlar.

B seçeneğini deneyen bir ekibin tekrar yoluna girmesine yardımcı olmak için sözleşmeli olarak görev aldım.

Dikkate alınması gereken birkaç şey.

• Düzeltmeleri tüm etkin kod dallarında ileriye taşıyın. Bu, birleştirme, yama ve / veya yeniden geliştirme ile yapılabilir. Bir düzeltmenin tüm uygun sürümlere, ardından gövdeye uygulanmasını sağlamak için tamamen yönetilmelidir.
• Ana kod akışından ayrı olarak özelliklerin geliştirilmesini sağlamak için özellik dallarını düşünün. Bunlara deneysel değişiklikler yapılması tavsiye edilir. Özellik çalışmazsa özellik dallarını terk etmekten çekinmeyin.
• Birleştirme noktalarını etiketleyin ve izleyin.
• Gerektiğinde bültenlerinizi dallayın. Normalde sürüm, sürüm aday yapıları için hazır olduğunda budur. Bazı durumlarda, gövdede uyumsuz değişiklikler yapılması zorlanmaya ve erken dallanmaya neden olabilir. Bir özellik dalını düşünün.

Birkaç yıl boyunca, tarif ettiğiniz iki şema arasında bir şey kullanan bir sistem üzerinde çalıştım. Anahtar, kullanımda çok seviyeli bir numaralandırma şemasının olmasıdır. Dış seviye temelde API versiyonudur ve dallarda yönetilir (bir şeyin birden fazla dalda düzeltilmesi gerektiğinde uygun çapraz birleşmelerle) ve iç seviye, etiketlerle yönetilen kesin sürümlerdir.

Özellikle, bir müşterinin tam sürümünün ne olduğunu bilirsek, kodun hangi kaynaktan oluşturulduğunu tam olarak biliriz ve tam olarak ne olduğunu tam olarak görebilmemiz için tam bir kopyasını yapabiliriz. Bu destek için çok önemlidir! Yine de, şu anda piyasaya sürdüğümüz API sürümlerinin dış seviyesi, zaman içinde gelişiyorlar (ana özelliklerin yeni özelliklerin çoğunu almasıyla). Ayrıca, API'nın yeni bir büyük sürümünü çıkardığımızda, bunu desteklemek için yeni bir şube yapıyoruz (böylece gövde her zaman sert çekirdek geliştirme odaklı olabilir) ve kullanım ömrünün sonuna gelip gelmeyeceğini düşünüyoruz dalı.

Bu yüzden gerçekten A ve B'nin bir karışımı olan bir şey öneriyorum ; her ikisinin de iyi yönleri vardır, fakat ikisi de kendi içinde tam değildir. Her iki dünyanın en iyisini kullanın.

Geçmişte (B) seçeneğini etkili bir şekilde uygulamak için TFS'yi kullandım.

Dallanma / birleştirme, küçük parçalar halinde yapıldığında harika bir araçtır. Zorluk bir dal yapmak (bu aptalca) ya da bir haftalık çalışmayı ağaca geri itmek (genellikle de kolaydır) ... CI sistemini otomatik olarak çalışmak için kaynak kontrolünüzün arkasında tutmaktır. sen.

Sistem otomatik olarak dalınız için testler oluşturmuyor ve çalıştırmıyorsa, dallanma tartışmalıdır.

Değişiklik kümelerinin göreli yollarını tanımak için TFS'nin varsayılan derleme iş akışını özelleştirdik ve özelleştirmenin yeni bir dalı tanıyabileceği bir kural belirledik (bazı geliştirme kökleri altında yeni bir alt klasör yerine). Düzgün, dallanması kolay, bir dalı öldürmesi kolaydı ve derlemeler ve testler için sistemimizden sürekli geri bildirim aldık.

Birçok insanın bu stratejilerin TFS kapsamında ne kadar imkansız olduğunu açıkladığını görüyorum ve bunun XAML tabanlı bir yapı motorunun olasılıklarına aşina olmadığından inanıyorum. TFS sadece kaynak kontrolü değil, tam bir çözümdür ve bu şekilde kullanılmalıdır.