Küçük bir takıma bir sürüm kontrolü dallanma politikası sunmak

Yakın zamanda bir firma ile başlayan bir müteahhitim.

Takım, 2 yeni ve orta seviye geliştiriciden oluşan 3 geliştiricidir, bir diğeri de yakında aynı seviyede başlar ve kendim (6 Yıllık xp). Her iki mevcut geliştirici için bu, üniversite / kolej dışındaki ilk işidir ve daha önce çalışmalarını denetleyen kıdemli bir geliştiriciye sahip olmamışlardır.

Açık bir Sürüm kontrol politikası yoktur. Geliştiriciler bagajdaki tüm gelişmeleri yapar ve daha sonra doğrudan geliştirme makinelerinden üretime dağıtırlar. Mevcut ekip dallanmaya aşina değildir.

Tüm bunları değiştiriyorum ve bunu iltifat etmek için bir sürüm kontrol politikası ile birlikte CI, TDD testi / evreleme / üretim sunucuları vb.

Kaynak kontrol sistemi, daha önce hiç kullanmadığım TFS'dir. Dev bir depo olarak yapılandırılmış.

Onlar için birkaç ipucu yazdım, ancak eklediğim / değiştirdiğim, ekibin deneyimini akılda tutarak başka bir şey var mı?

Sürüm Kontrol Politikası

Gövde üzerinde geliştirme yapılır

Bir değişikliğin bir haftadan fazla süreceği tahmin ediliyorsa, bir dalda, ikisinin senkronizasyondan çıkmasını durdurmak için gövdeden dala doğru düzenli birleşme ile yapılmalıdır.

Üretim kodu için oluşturulan şubeler. Bu dal yalnızca sabit kod içermelidir. Sprint başına bagajdan bir kez güncellenen bir sürüm şubemiz olabilir veya her hafta için ayrı bir sürüm şubesi oluşturabiliriz.

Üretim kodunu etkileyen acil bir hata düzeltmesi yapılması gerekiyorsa, serbest bırakma dalında yapılır ve bagajda yeniden birleştirilir.

Eğer bir serbest bırakma dalı stratejisini benimsersek, o zaman gövde serbest bırakma dalına sprint başına bir kez sprint sonuna doğru birleştirilir.

Sürüm stratejisi başına ayrı şubeyi kabul edersek, bagaj ASLA Sürüm şubesine birleştirilmez

Bazı senaryolarda, dallar çok fazla sapmışsa, hatanın farklı dallarda iki kez düzeltilmesi gerekebilir. Kısa sprintler yapıyorsak, bu çok sık olmamalıdır.

Üç sunucum var. Depodaki her zaman en son kodu çalıştıran ortam test edin. Sürüm Adayı / Test Adayı kodu ve UAT amaçları için en yeni sürüm adayını ve üretim ortamını çalıştıran bir hazırlık ortamı.

Bunu yapmayı planlamamın nedeni, şu ana kadar istemcinin yalnızca dahili yazılım yapmasıdır. En yeni proje, yüksek profilli bir medya müşterisi için ve benim düşüncem, ekibin şu anda yaptıklarından daha profesyonel bir gelişim modeli benimsemesi gerektiğidir.

Örneğin, şu anda bir kullanıcı ekibi bir hata raporu ile arayabilir. Geliştiriciler hatayı bulur ve düzeltir, kendi makinelerinde hızlı bir test göz küresi testi yapar ve daha sonra doğrudan üretime yerleştirir. Otomatik test veya başka bir şey yok.

Gez, özellik dalı çok bir adım olduğunu düşünüyorum ve bunu kaldıracağım.

Dolayısıyla esasen a) hiç dallanma olmaz) b) bir serbest bırakma dalı ve gövdesi ve c) serbest bırakma ve gövde başına bir serbest bırakma dalı.

Ben ikincisine doğru eğildim. İlk düşüncem, hem ayrı bir sunucuda (UAT / Production) hem bir yayın adayı hem de yayın için bir sürümüm olacaktı, ancak etkili bir şekilde gövde, herhangi bir zamanda sürüm adayı olacaktı, bu nedenle şube başına serbest bırakma deliğe doğru eğiliyor. Tek düşüncem, paydaşlarımızın gelişim kodunu görmelerini istemeseydik, ayrı bir sürüm aday şubesine ihtiyacımız olabilirdi, ancak YAGNI ve tüm bunlar .....

3-4 devs'lik bir ekip için, WAY çok fazla şube öneriyorsunuz.

Oluşturduğunuz her dal, bir maliyetle birlikte gelen ek bir ek yüktür (birleştirme için harcanan zaman, neyin nerede olduğunu takip etme vb.). Bir şubeye sahip olmanın getirdiği faydanın maliyetten daha ağır bastığından emin olmalısınız.

Bir branşman için tek gerçek yararın kod yalıtımı olduğunu unutmayın. Bu, kodu izole etmek için somut bir nedene ihtiyacınız olduğu anlamına gelir.

Her sürat için ayrı bir salıverme dalı olması deliliktir. Neden bir sprintten diğerine koddan izole edilmiş bir koda ihtiyacınız var? Neden sadece her sprint ile ilerleyen tek bir kararlı serbest bırakma dalına sahip değilsiniz?

Bir değişikliğin bir haftadan fazla süreceği tahmin ediliyorsa, bir dalda, ikisinin senkronizasyondan çıkmasını durdurmak için gövdeden dala doğru düzenli birleşme ile yapılmalıdır.

Önemsiz yeni özelliklerin neredeyse tamamı, geliştirme, geliştirici testi, günlük kesintiler ve diğer etkinlikler vb.

Ayrıca, "düzenli birleşme" nedir? Günlük? Haftalık? Yaptığınız her birleştirme zaman alır - değişikliklerinizin ardından hedef birleştirme dalının oluşturulduğundan ve çalıştığından emin olmanız gerekir. Küçük bir ekipte, sık birleşme çok fazla ek yüktür.

1 milyondan fazla satır kod tabanında çalışan 4 geliştiriciden oluşan bir ekibimiz var ve şu şekilde çalışıyoruz:

• Tüm gelişmelerin yapıldığı ana şube
• Başlıca sürüm başına bir şube (yılda yaklaşık bir kez yapılır)

Tek büyük kural şudur: Oluşturulmayan kodu kontrol etmeyin.

Bu kadar. Basit, anlaşılması kolay, ihtiyacımız olan izolasyonu alır (herhangi bir zamanda herhangi bir sürüm için bir sürüm oluşturma oluşturabiliriz).

Tüm geliştirme çalışmalarının bir dalda yapılmasının olumsuz yanları:

1. Geliştiriciler her zaman birbirleriyle senkronizedir. Acı verici birleşme yok çünkü iki geliştirici uyumsuz değişiklikler yaratarak haftalarca kendi dallarında çalışıyordu.
2. Aynı gün kırık yapılar bulunur. Her gece en son kodu çalıştıran bir derlememiz var. Birisi herhangi bir nedenden ötürü oluşturulmayan kodu kontrol ederse, hemen bileceğiz.
3. Herkes her zaman aynı kod üzerinde çalışırken, bir hatanın daha sonra değil, daha erken bulunma şansını artırır.
4. Dalları serbest bırakmak için hedeflenen düzeltmeler dışında birleştirme ek yükü yoktur. Küçük bir takımda, büyük olan bu.

Onlar için birkaç ipucu yazdınız, ancak yaklaşımınızın neden zaten kullandıklarından daha iyi olduğunu açıklamadınız . Bu sorunlu olabilir. Eğer bir ruh halindeyseniz “Bunu kendi tarzımla yapacağız, çünkü altı yıllık mesleki deneyimim var ve siz yoksunuz” (ve sorunuzu okumak, tam olarak bu şekilde görünüyor), nefret etmeye hazır olun konseptlerinizi uygulamak için yapamayacakları her şeyi yapmaya çalışan ekip üyeleriniz.

Çözülmesi gereken bir sorunları var mı? Öncelikle bu soruyu cevaplamak çok önemlidir, çünkü ya gerçekte bir problemleri vardır ve önerilerinizi memnuniyetle karşılayacaklar ya da şu anda yaptıkları gibi mükemmel şekilde çalışıyorlar ve sadece tercih ettiğiniz için onlara çalışma şeklinizi itiyorsunuz. bu şekilde çalışın.

Sonunda, onları şube kullanmaya zorlamak son derece olumsuz bir etkiye sahip olabilir . Bir gövde ile çalışmak özellikle Agile ortamında kolaydır. Bir geliştirici, bagajda değişiklikler yapar ve sonunda küçük çakışmaları ele alır ve bu değişiklikler Sürekli Entegrasyon platformu tarafından hemen kullanılır. Şubelerle:

• Bir geliştirici, değişikliğin nerede bulunması gerektiğini düşünmelidir,

• Birinin dalları yönetmesi ve dallardan gövdeye birleşmesi gerekir,

• Şubeler arasındaki birleşme taahhütlerden daha az yapılır, yani birisinin iki taahhüt arasındaki bir anlaşmazlıktan daha büyük ve ele alınması daha zor olan çatışmalarla başa çıkması gerekir,

• Her taahhüt, geliştiricilerin bir taahhüdün sahip olabileceği etkiler (özellikle gerilemeler) hakkında elde ettiği bilgileri geciktiren Sürekli Entegrasyon'a giden yolu bulmaz.

Gerçek şu ki:

Mevcut ekip dallanmaya aşina değil

işleri daha da kötüleştirir. Deneyimsiz bir menajerin şubelerle oynamaya karar verdiği deneyimsiz programcılardan oluşan bir ekipte çalıştım. Bu, çok fazla ( çok ) zaman kaybına neden oldu ve son teslim tarihleri ​​olan bir proje için tam olarak kaçınmak istediğiniz şeydi.

Mainma'nın dediği gibi, dallara dikkat edin. Birkaç haftada bir dallanmadan bahsediyorsun, çok fazla dalın olması gerçekten gerekli mi?

Alternatif olarak, push modeli yerine 'pull' modeliniz de olabilir. Git veya Mercurial kullanıyorsanız, merkezi sunucuya geçmeden önce değişikliklerini doğrulayan bir tümleştirme sunucunuz olabilir. TFS'de, girişli girişleri kullanarak benzer bir şey yapabilirsiniz . Bu şekilde, validasyona sahip olabilir ve dalların karmaşıklığını önleyebilirsiniz.