Uzun süredir yayınlanmamış kod için Git dallanma stratejisi

Ekibimizde, bireysel çalışma birimlerine (Hikayeler) ek olarak, daha uzun süren çalışma temalarımız var (Destanlar). Birden fazla hikaye destansı.

Geleneksel olarak, her bir Öykü için özellik dallarımız vardı ve bunları KG'yi geçtiklerinde ustalıkla birleştirmek için birleştirdik. Ancak, Epic "özellik tamamlandı" sayılana kadar, bir Epic'te tamamlanmış hikayelerin yayınlanmasına devam etmek istiyoruz. Bu özellikleri yalnızca tüm Epic kapalıyken üretime sunacağız. Ayrıca, her gece oluşturulmuş bir sunucumuz var - tüm kapalı Hikayelerin (tamamlanmamış Destanların bir parçası olanlar dahil) bu gece sunucusuna otomatik olarak dağıtılmasını istiyoruz.

Bunu başarmak için depomuzu nasıl yöneteceğimize dair herhangi bir öneriniz var mı? Doğrudan epik dal yerine ilgili epik dal ile kapalı hikayeleri birleştirdiğimiz "epik dalları" tanıtmayı düşündüm, ama endişelerim şöyle:

• Destansı şubeler uzun süre açık tutulursa ortaya çıkabilecek birleşme çatışmalarından endişe ediyorum
• Gece yapıları, tüm destansı dalları bir "gece yapısı" dalına birleştirmeyi gerektirir. Yine, birleşme çatışmaları ortaya çıkabilir ve bu otomatik olarak yapılacaktır

Basit bir öneri: bunu yapma.

git dalları, burada tartışıldığı gibi ve https://blog.newrelic.com/2012/11/14/long-running-branches-considered-harmful/ kodunun uzun süre çalışan çatalları için değildir . Dallar en iyi şekilde, bireysel bir geliştirici tarafından günlük düzeyde taahhütleri düzenlemek için kullanılan geçici şeyler olarak ele alınır. Dolayısıyla, bir proje yöneticisine (son kullanıcı olsun) yanlış bir şey yaptığınızı umursadıkları bir şeye karşılık gelen bir isimleri varsa.

Önerilen uygulama, aşağıdakileri sağlamak için özellik geçişleri veya soyutlama ile sürekli entegrasyon kullanmaktır :

• tüm kodlar her zaman entegre edilir (en azından her gün, tercihen daha sık)
• Ne olur konuşlanmış açık kontrolü altındadır.

Bu oldukça yaygın bir sorun olduğunu düşünüyorum ve özellikler daha önce değil kodlandıktan sonra bir sürüme dahil edilecek özellikleri seçmek için kaynar.

Örneğin.

Ürünümün v2'si için A, B ve C özelliklerine sahibim. B ve C ilişkilidir, C de bitmedikçe B'yi bırakmak istemiyorum.

Tüm özellikler üzerinde aynı anda çalışan üç geliştiricim var.

Taş çıkış tarihi D'de bir setim var

B bitti ve birleştirildi, A bitti ve birleştirildi. C ertelendi ... ne yapmalıyım ?!

Bu sorunun teknik bir çözümü olduğuna inanmıyorum. Ürünün test edilmemiş bir sürümünü yalnızca A özelliği dahil olmak üzere serbest bırakmak istiyorsunuz. Mümkün olan tüm özellik kombinasyonlarını birleştirip test etmedikçe, bu her zaman bir olasılık olacaktır.

Çözüm daha insani bir çözümdür. Çıkış tarihinizi kaçırdınız ve geri itmeniz gerekiyor.

Bu zor bir sorun ama birçok insanın karşılaştığı bir problem. Gitflow kurulumunu başlangıç ​​noktası olarak kullanmayı tercih ederim.

Geliştirme ->
Master üzerinde çalışılan yeni şeyler -> Teste ihtiyaç duyan bitmiş ürünler Üretim -> Üretime yayınlanmış olan şeyler.

Küçük (daha kısa) özelliklerde, geliştirmeden bir dal yaratırım, oradaki işi yapar, sonra da dalı gelişime geri birleştiririm.

Başlıca (uzun vadeli) özelliklerde gelişimden bir dal oluşturur, o daldan daha küçük dallar oluşturur, sonra ilk dalla birleşirim. Başlıca özellik tamamlandıktan sonra geliştirme dalına geri döner.

Düzenli aralıklarla (projeye bağlı olarak) gelişimi tekrar master ile birleştiriyorum ve bir test döngüsü başlıyor. Testte herhangi bir düzeltme ortaya çıkarsa, ana dalda yapılırlar (alt dal sonra birleştirilir). Ve test sırasında ana dalda geliştirme devam edebilir.

Herhangi bir zamanda usta gelişimle birleştirilmeli ve kalkınma uzun vadeli alt dallarından herhangi biriyle birleştirilmelidir.

usta her zaman (teoride) üretime hazır olmalıdır. Kalkınma her zaman (teoride) üretime hazır olmalıdır. Test etmenin test etmesi için sağlam bir özellik kümesi sağlamanın tek nedeni budur.

Hazır olduğunda, test edilen bir master taahhüdü üretimle birleştirilir ve üretimde dağıtım bu branştan gerçekleşir. Acil bir durumda yapılması gereken HOTFIX'ler, Master'da birleştirilmeye gerek kalmadan Üretim branşında gerçekleşebilir (test edilmemiş birçok değişiklik olabilir).

Normal Ağacım benziyor

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production  

Genel kuralım, hiçbir değişikliğin birkaç saatten fazla sürmemesi gerekir. Eğer öyleyse, daha küçük değişikliklere yapılması gerekir. Büyük bir özellikse (UI yeniden yazma gibi), uzun vadede devam eder, böylece normal gelişim aynı anda devam edebilir. LongTerm şubeleri normalde sadece yerel şubeler, Geliştirme, Master ve Üretim ise uzak şubelerdir. Alt dallar da yalnızca yereldir. Bu, uzun vadeli özellik kümesinde git'in kullanışlılığını kaybetmeden depoyu başkaları için temiz tutar.

Bununla birlikte, uzun vadeli bir şubenin varlığının nadir bir şey olduğunu belirtmek isterim. Normalde tüm işlerim geliştiriliyor. Sadece normal geliştirici şeyler üzerinde çalışabilmem gereken kadar uzun sürecek bir özellik (set) olduğunda, LongTerm dalını kullanırım. Eğer birlikte olması gereken bir takım değişiklikler varsa, o zaman hepsi bitene kadar ustalaşmak için birleşmem.