çoklu havuz ortamında paket ve sürüm stratejileri

Biz kendi git depolarını yöneten çok sayıda takımı olan küçük bir şirketiz. Bu bir web platformudur ve her takımın eserleri günün sonunda gece testleri için konuşlandırılır. Süreci versiyonlama ve paketleme etrafında resmileştirmeye çalışıyoruz.

Her takımın günlük gelişim yaptıkları bir ana dalı vardır. Her bir ekibin kalite güvencesi üyeleri, ekibinin yaptığı değişikliklerin eserlerinin, tüm bileşenlerin şef tarafından birleştirildiği bir test yatağına yerleştirilmesini istiyor. Eserler tarball'lardır, ancak sürümleri doğru düşünüp düşünebilmemiz için RPM'lere dönüştürmek istiyorum.

Salım işlemi, git depolarının her birinin geliştirme dalından (çoğu durumda master) bir ayırma dalının kesilmesini içerir. Bu daha sonra testler yapan ve bir dizi esere imza atan kalite güvencesine verilir.

Örneğin, bu, ilişkili serbest bırakma dalları ile tipik bir git deposudur:

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

Geliştirme dallarından gelen paketlerin sürümlendirilmesi için bir plan bulmaya çalışıyorum. Her bir reponun ana dalını aşırı şekilde etiketlemek ve etiketleri yalnızca şubeleri serbest bırakmak için kısıtlamak istemiyoruz. Ancak standart yum / rpm semantiği kullanarak test makinelerinde konuşlandırılmış paketleri sorgulayabilmeliyiz. Ana dalda etiket olmadığında geliştirme sürümleri nasıl görünür? git describeBana bir yapı sürümü yararlı bir temsil sağlayabilir anlıyorum ama şube çeşitli yayın noktaları etiketlendiğinde iyi çalışır.

EDIT1: @ Urban48'in cevabına yanıt olarak

Serbest bırakma sürecimizi biraz daha açıklamam gerektiğini düşündüm. Bu tartışmanın amaçları doğrultusunda, mastertüm depolarda şubemiz olduğunu varsayalım . masterŞube geliştirme şube olarak kabul edilir ve bir otomatik CI-CD dağıtıldığı QA ortamı sağladı. Master'ın stabilitesini sağlamak için gece testlerinin bir alt kümesi burada çalışır. Bir serbest bırakma dalını kesmeden önce bu iş hattına bakıyoruz. Serbest bırakma kollarımız kısa ömürlüdür. Diyelim ki, bir serbest bırakma dalını (istikrarlı bir masterdan) kestikten sonra, tam bir gerileme gerçekleştirilir, düzeltmeler yapılır ve üretime uygulanır. Bu işlem yaklaşık bir hafta sürer. Neredeyse iki haftada bir üretime geçiyoruz.

Özellik dallarımız her zaman master'dan kesilir ve CI-CD stabilite kontrollerine tabi oldukları master ile birleşmeden önce bir miktar geliştirici testine tabi tutulur.

Düzeltmeler düzeltme dallarında (serbest bırakma dallarından kesilmiş) yapılır ve üretime en az etki testi ile dağıtılır.

Sürüm ve düzeltme dalları için sürüm oluşturma stratejimiz semver'i takip eder. KG döngüsü sırasında sürüm dalları v2.0.0-rc1, v2.0.0-rc2KG oturumu kapatıldıktan sonra ve son olarak KG sürümlerinden geçer v2.0.0.

Bazen sürümleri haline geldiğinde dalları serbest bırakmak (ve sonra master yapmak) için birleştirilen küçük özellikler için noktalı sürümler yaparız v2.1.0. Ve düzeltmeler v2.1.1deseni varsayar .

Ancak soru, bu şubelerin versiyonlanmasıyla ilgili değildir. Bu sürüm şemasını tamamen değiştirmemeyi tercih ederim. Tek değişiklik kalkınma dalı için yani. usta. CI-CD ortamında önceki sürümün üretime geçtiği sürümün nasıl güvenilir bir şekilde gösterebilirim. Bu ideal olarak akıllı git etiketleme yoluyla yapılabilir, ancak ana dalı aşırı derecede etiketlemeyen bir şey tercih edilir.

Hmm, teknoloji agnostik olabilecek bir .net örneğim var.

Hızlı bir özet yapacağım.

• gitflow dallanma stratejisi ile bileşen başına git repo

• bir takım şehir inşa tetiklemek geliştirmek için tüm taahhütler

• teamcity build, manuel major minor + AssemblyInfo.cs içindeki yapı numarası ile versiyonu değiştirir, yani 1.1.hotfix.build

• teamcity, yayınlanan nuget kütüphaneleri için aynı sürüm numarasını kullanarak nuget paketlemesini tetikler

• ahtapot, manuel test için bitmiş derlemeyi qa'ya dağıtır (tüm testlerin geçtiği varsayılarak)

• her şey yolundaysa, ahtapot aracılığıyla üretime manuel olarak dağıtın.

Şimdi bu, hakkında yüzen çok sayıda paketlenmiş paket elde ettiğiniz anlamına gelir. -Pazarsızlık bayrağını kullanmayı denedik, ancak bu, başlangıç ​​aşamasından 'normal' adıma başka bir manuel taşıma paketi ve bunlara bağlı bileşenleri yeniden oluşturma gereksinimi gerektiriyordu.

Önemli olan, her yapıyı bazı merkezi süreçlerle benzersiz bir şekilde versiyonlamaktır.

O zaman 'hmm' hangi sürümleri istiyorum 'yerine' omg, hangi sürüme sahibim? '

Düzenleme: yeniden yorumlar.

Sadece bu anahtar şeyin altını çizmek. Hangi şubenin tamamlanmış yazılımı oluşturduğuna ve ALL sürümünün kendisine bağlı olduğuna karar verin . bu sürümden yalnızca sürümlü yazılımlar dağıtabilirsiniz.

Benim görüşüme göre dallanma stratejinizi ele almanız gerekiyor.

• özellik (veya herhangi bir dev) dalı sürümlemeyin.
• sürüm ustası yap
• sadece master paketlerini kullanın

Sürüm oluşturma sorununuzu çözebilecek alternatif bir iş akışı sunmama veya yalnızca çözüme yönelik daha fazla yol düşünmenize yardımcı olalım.

Önce biraz felsefe ..
(İş akışınız hakkında birkaç varsayımda bulunuyorum, lütfen yanılıyorsam beni düzeltin)

1. Testler geriye dönük olarak yapılır :

   Dal maser, özellik dalından çıkarılır ve ardından KG tarafından test edilmek üzere bir yapay yapıya dönüştürülür.
   sorun şudur : ya testler başarısız olursa masterkırılabilir!

   yan etkiler:

   • Geliştiricilerin güvenmemesini sağlar master

   • Ustadan şubeleri serbest bırakmak için dallandığınızdan, önceki sürüm bozulursa ne olur? master tekrar düzeltilene kadar yeni özellik entegrasyonunuzu durdurur.

   • sürüm dalında hata düzeltildiğinde, masterbirleştirme çakışmaları oluşturabilecek şekilde geri birleştirin. (ve çatışmaları sevmiyoruz)

2. küçük kod birleştirme ve düzeltme :

   masterBelirli bir özelliğin parçası olmayan küçük düzeltmeler veya değişiklikler gibi birleştirilen tüm kodları takip etmek zordur .

   yan etkiler:

   • geliştirici şu anda veya daha sonra bu küçük düzeltmeyi birleştirip birleştirmeyeceğinden emin değil.

   • Ben de bu yeni küçük düzeltme sürümü gerekir?

   • Herhangi bir zamanda, masterdalın durumu ve orada hangi kodun yüzen olduğu net değil

   • bir şey inşayı kırdı, bu yeni özelliğin bir parçası değil. ve nereden geldiğini izlemek gerçekten zor

Git iş akışı için düşüncem şu şekildedir:

mastersizin gibi yeni özellik geliştirme için şube dışarı . ancak şimdi bu yeni oluşturulan şubeden ayrılmak yerine, bu özelliği kirazla toplayıp releaseşubeye birleştirin .

Artık belirli bir sürümde neler olup bittiğini daha iyi kontrol edebilirsiniz.
Geliştirme sürümlerini ve kararlı sürümleri izole etmek gerçekten çok kolay.

KG için bu özellik dallarından eserler oluşturmaya devam edebilirsiniz.
Her şey yolundaysa, bu özelliği geri birleştirin masterve bu özelliği / bug-fix / hot-fix'i serbest bırakma dalı içine alın.

versioning
Özellik dalları sürümü aşağıdaki gibi bazı ad kurallarını kullanabilir1.2.3-rc.12345

releasedaldaki sürümler yalnızca kullanır 1.2.3 ( 1.2.3> 1.2.3-rc.12345endişelenecek bir şey daha az)

Bu iş akışı yukarıda belirtilen sorunları ve daha fazlasını giderir.
Ayrıca aklı başında sürüm oluşturma stratejisi öneriyor ve bu sürüm döngüsünün çoğu otomatikleştirilebiliyor.

Umarım bir şekilde size yardımcı olur, karşılaşabileceğiniz herhangi bir son durumu memnuniyetle tartışacağım.

ps:
İngilizcem için özür dilerim, bu benim ana dilim değil.

İşleminiz çok kıvrımlı görünüyor ve az sayıda etiket almak kaçınılmaz görünüyor.

İki fikir akla geliyor:

1. "Ana" dala "geliştirme" dalına tipik olarak sahip olduğumuz gibi davranırsınız. Bu mesaj dalını çok kirletir.

2. KG işlerini bitirdiğinde, kullanılan tüm depoların etiketlerini içeren bir rapor (ör. Bir metin dosyası) oluşturmak için build / CI sunucusuna sahip olabilirsiniz. Şimdi repoya gönderilebilecek sürümleri olan bir dosyaya sahip olacaksınız. Daha sonra şubeyi yalnızca yayın sürümü ile etiketlersiniz ve bileşenlerin sürümlerini tek tek kontrol etmek isterseniz raporu kontrol edebilirsiniz.