Karmaşık bir dallanma gerçekliğinden tek dallı bir modele nasıl geçilir?

Büyük organizasyonlarda, şelale metodolojisinin kullanılması tipik olarak çok karmaşık dallanma yapılarına ( dal spagetti olarak ) neden olur.

Karmaşık bir dallanma gerçekliğinden, gövde tabanlı gelişme gibi tek dallı bir modele geçiş yapmak için hangi dallanma stratejileri kullanılabilir?

Güncelleme:

Açıklığa kavuşturmak gerekirse, soru, oldukça açık olan önceki ve sonraki metodolojilerle değil , göç / geçişin kendisiyle ilgilidir .

Gerçekten "EOB'de bugün hala milyarlarca şubeyle şelaleyiz, ancak yarın 1. şey gövde tabanlı, tek dallı CI'ye geçeceğiz".

Şelaleden bahsettiğiniz için, anladığınız sayısız dalın bakım dallarından ziyade özellik dalları olduğunu anlıyorum.

Bu kurulumda, bu dalların çatışmaları en aza indirmeye çalışan bir şelale planına göre oluşturulduğunu da varsayıyorum. Bu, geliştirmenin amacının birkaç farklı ürün üretmektir. Tek dallı bir geliştirme modeli kullanırken, tek bir ürün üzerinde de çalışmak önemlidir. Birçok ürünün aynı anda tek dal geliştirme modelinde geliştirilen bu etkin yüzden versiyon içinde olabileceğini tezler ürünlerin “yapıştırır” birlikte versiyonları, a depo sağlıklı ürünü X ve bir arabası ürün Y , ise versiyon içinde b ürün X'in bir gerileme vardır ve Y bir hata düzeltme, ama biz hiçbir sürümüne sahip nereye hem X veY sağlıklı. Böyle bir durum bizi X ve Y'yi farklı depolarda geliştirilmiş olarak görmeye zorlar , ki bu olması gereken bir ipucu.

Bu nedenle, ilk adımlar bir depo bölmesi gerçekleştirmelidir :

1. Depoyu, birkaç küçük depoya bölmek kolay olacak şekilde düzenleyin. Örneğin, geçerli havuzu, her bir üst düzey dizinin gelecekte oluşturmak istediğiniz bir depoya karşılık gelecek şekilde yeniden düzenleyin. Böylece, herkesin bildiği dal spagetti disiplini kullanmaya devam edebilirsiniz .

2. Adım 1 tamamlandığında, herhangi bir dalın yalnızca bir üst düzey dizindeki dosyalara dokunmasını gerektirerek dal spagetti disiplinini geliştirin .

3. Her dal 2. adıma uyduğunda bölünmeyi gerçekleştirin. Geliştiriciler, yalnızca yolun ilk düzeyini kaldırarak beklemedeki değişikliklerini tek bir havuzu düzeltmek için kolayca dönüştürebilirler.

Bölünme gerçekleştirildiğine göre, şube disiplini üzerinde çalışmaya başlayabilirsiniz.

4. Kısa ömürlü dalların gelişimine yardımcı olan programlama tekniklerini tanıtmak. Şubelerin kısa ömürlü olması, tek branşlı metodolojilerin hayati bir yönüdür. Amaçlarından biri, uzun ömürlü şubelerin birleştirilmesi ve hata ayıklanması için harcanan zamanı azaltmaktır. Popüler bir teknik, bir "fabrikanın" bir nesnenin tarihi sürümünü veya o nesnenin başlangıçta kısmen geliştirilmiş olan yeni sürümünü üretmek için bir yapılandırma bayrağı kullandığı "özellik bayrakları" nın tanıtılmasıdır.

5. Şimdiye kadar, her birinde sadece birkaç şubesi olan milyonlarca deponuz var ve gövdede çöken orijinal şube spagetti dağını görmeden “küresel olarak temel tabanlı geliştirme disiplini benimsiyoruz” düğmesini çevirebilirsiniz .

Gerçek depo bölmesi isteğe bağlı olabilir, ancak daha sonra gönderilen her bir yamanın izin verilen kapsamını temiz bir şekilde tanımlayan politikalar benimsemeniz gerekir (ana daldaki değişiklikleri birleştirirken çatışma riskini sınırlamak için). Çatışmalara bağlı yükü azaltmak, tek dallı model metodolojilerinin amaçlarından biridir, bu yüzden bunun bağlamınızla ilgili olduğunu varsayıyorum.

Bir şeyden başka bir şeye geçerken, tanımlamanız gereken sadece iki şey vardır:

1. Hedefin ne
2. Nasıl Gidilir (Göç Planı)

İlk bölüm ne yazık ki, genellikle gözden kaçan veya olduğu yolu çok belirsiz. Sahip olduğunuz şeyin bir karışıklık olduğunu ve onu düzenlemek istediğinizi söyleyemezsiniz. Bu ne anlama geliyor? (: Her geliştirme düşünüyor aka Herkes farklı bir yorum olurdu onun veya onun şeyler yapmanın yolu en iyisi).

Şansınız, hizmet verdiğiniz veya bir amaca hizmet etmiş olduğunuz tüm şubelerdir. Açıkça tanımlanmış bir hedef süreci olmadan, insanlar kendileri için en uygun olanı (ve haklı olarak) gerçekleştirmeye devam edecektir.

Örneğin, hedefiniz Vincent Driessen'in "başarılı Git dallanma modeli" tanımladığı kadar açık bir şekilde tanımlanmalıdır . Bu modele bakarsanız, çok hassastır: Kararlı kodun nerede olması ve kararsız özelliklerin nerede geliştirilmesi gerektiğini söyler. Ayrıca nasıl, ne zaman ve nasıl dallanacağını, güncelleneceğini ve birleştirileceğini açıklar. Her dalın ne için olduğunu ve onlarla ne yapacağını biliyorsunuz. Vincent'ın ortaya koyduğu şeyin bir varyasyonunu kullanıyoruz ve varyasyonumuz wiki'mizde tanımlanıyor.

Önemli olan, tüm ekibin bir hedefi anlaması ve kabul etmesi. İnsanlara kişisel favori dallanma modelini aramadıklarını hatırlatmaya değer olabilir, ancak tüm ekip üyelerinin üzerinde anlaşabileceği ve kolayca kullanabileceği bir model.

Hedefinize ulaştıktan sonra, geçiş planınızı ayrıntılı bir şekilde hazırlayabilirsiniz. Bu plan istediğiniz kadar uzun veya kısa olabilir. Bu dallanma modelini bir gecede dayattım; diğer yerlerde, 2 veya 3 sprint üzerinden yapıldı. Geliştiğimiz sürece benim için çok önemli değil.

"En büyük" veya daha önemli dallarla başlayabilirsiniz. Örn: "bundan böyle, master daima prod'da konuşlandırılacak bir durumda olmalı ve geliştirici dalı daima derlenmelidir" (veya kurallarınız ne olursa olsun). Ardından, sürüm (sürüm) dallarını zorunlu kılın. Daha sonra, özellik dallarını uygulayın. Bundan sonra, mantıklıysa, sürüm dalına bir kod dondurma uygulayın.

DevOps tamamen iletişim, açıklık ve verimlilik ile ilgilidir. Bu kavramlar akılda tutulmalı ve süreç boyunca iletilmelidir.

Geliştirme ekibinin dışındaki bazı kişileri süreç toplantısına gözlemci olarak davet etmenizi öneririm. Operasyonlar veya orta yönetimin modeliniz hakkında söyleyecek bir veya iki şeyi olabilir. Geliştiricilerin ihtiyaçlarına öncelik verilmelidir, ancak dallanma modelinin işlerin yönetilme şekline uyması imkansızsa, bir veya iki ay içinde değil, şimdi daha iyi bilirsiniz.

Gerçekten büyük takımlarınız varsa, yine de herkesi dahil etmeye çalışın. Çok büyük ekiplerle, yine de iki veya üç toplantıyla sonuçlanacaksınız. Bu yüzden odadaki takım liderlerini davet edin, ancak bir web yayını hazırlayın ve herkese bunu bildirin. Herhangi birinin bir öneri veya endişesi varsa, bunu ekip liderlerine söyleyebilecek ve geçerliyse ikinci veya üçüncü toplantıda ele alınacaktır.

Çok dallı bir hidra deposunu tek dallı bir modele dönüştürmek aslında çok basittir.

İlk olarak, kendisi ile usta veya gövde arasında en az farkı olan dallarla başlamak istersiniz. Yaşlarını ve alaka düzeylerini inceleyin. Hâlâ alakalı ise, bunları bir araya getirmeye ve çatışmaları çözmeye başlayın. Artık alakalı değilse, silin.

Tüm dallarınızı birleştirmeyi başarana, tüm çakışmaları çözene ve yalnızca tek bir dalınız kalıncaya kadar bu işleme devam edin.

Başlamak için bu basit anahattı takip edebilirsiniz:

1. Ana / ana dalınızın bir kopyasını oluşturun ve arayın temp_master
2. Ana / gövdeden en büyük ayrımı olan dalı bulun.
3. Şubenin saklanması, arşivlenmesi veya silinmesi gerekip gerekmediğini belirleyin.
   1. Tutulması gerekiyorsa 4. adıma geçin.
   2. Silinmesi veya arşivlenmesi gerekiyorsa, silin ve arşivleyin ve ardından 2. adıma dönün.
4. En az ıraksama ile bir sonraki dalı bulmak için 2. adımı tekrarlayın.
5. Adım 2 ve adım 3'te bulunan iki dalı birleştirerek tüm çakışmaları çözün.
6. Bu iki dalınızı dalınıza birleştirin temp_master.
7. Derlenmiş ve derlenmiş olup olmadığını görmek için temp_master kodundaki kodu test edin ve akıl sağlığınız için diğer tüm otomatik testleri çalıştırın.
   1. Herhangi bir test başarısız olursa, geri dönün, nedenini bulun ve düzeltin ve işlemi tekrarlayın.
   2. Testler hala başarısız olursa, çalışmak için iki farklı dal seçin.
8. Master / trunk ve sadece iki dalınız olana kadar 2 - 7 arasındaki adımları tekrarlayın temp_master.
9. Son olarak, temp_mastermaster / trunk ile birleşin ve yeni tek dallı modelinizle yaşayın.

Tipik 4 hafta sürat döngüsü ile büyük kuruluşlar için Git-Akış Sen Özelliği şube Usta üretim hazır dalı yararı Ayrıca her zaman konuşlandırılabilir olsun, çünkü ikisini takip ederek ana dal istenmeyen kaydedilmesini gelen temiz tutulur, yaklaşım tercih edilir özellikten için döngüsünü (işlemek Developve Developşube Master).

Ayrıca dallanma, üretim salımlarının sıklığı ile de belirlenir. Üretime sık sık dağıtım için bir Özellik şubesine veya Merkezi bir modele sahip olmak daha iyidir. Bu durumda, şube yönetim yükü, üretim kararlılığını korumak için düşük ortamlarda sağlam testlere kaydırılır.