git, maven ve jenkins - sürüm oluşturma, geliştirme ve yayınlama iş akışını oluşturur

Git, maven ve jenkins ile aşağıdakileri yapmanın tercih edilen yolu nedir:

"Dev" ve "release" şubelerini sürdürmek istediğim bir uygulama geliştiriyorum. Jenkinlerin ikisini de inşa etmesini istiyorum. Serbest bırakma yapılarının 1.5.2 gibi sürümlere sahip olması ve dev-build'lerin sadece 0.0.1-SNAPSHOT'lar olması olabilir. 2 farklı pom.xml dosyasına sahip olmak istemiyorum.

Profillere baktım, ancak artefakt versiyonlarını değiştiremiyor gibi görünüyorlar. Baktığım bir yol, test sürümlerine bir 'niteleyici' eklemek olabilir. Tabii ki dosyayı yeniden adlandırabilirim, çünkü bu uygulamadaki gerçek eser bilgisi önemli değil, çünkü uygulama bağımsız bir dosya.

Bunu yapmanın tercih edilen yolu ne olurdu? Ya da bunu nasıl yapardın?

Bu şubeler arasında sürüm numaraları sorununu çözmesi gereken doğal bir ilişki olması gerektiğini düşünürüm.

Releasing

Geliştirme dalından sürüm şubesine birleştirme üretimine hazır kod gibi bir şey yapabileceğinizi, ardından bir Maven sürümü (Jenkins veya manuel olarak) gerçekleştirebileceğinizi düşünürdüm. Bu, sürüm numaralarını otomatik olarak sonraki yapıya döndürür. Böylece 1.4.7-SNAPSHOT kodunu bu şubeyle birleştirir, sürüm 1.4.7'yi serbest bırak ve kes işlemini gerçekleştirirsiniz ve Maven otomatik olarak çalışma kopyanızı 1.4.8-SNAPSHOT'a alır.

Temel Güncelleme (isteğe bağlı)

Bagajınızı (veya taban çizgisi dalınızı vb.) Yayınlarınız için bir yer olarak kullanmıyorsanız, bir sürümü tamamlar tamamlamaz bagajınızı güncellemelisiniz. Bu, sürüm numaralarınızın da güncellendiği anlamına gelir. Eğer serbest bırakma dalını temel olarak değerlendirirseniz, bu adım tartışmalı olabilir.

Baseline'dan Dev Branch'a birleştirme

Geliştirme şubenizin gerçek üretim koduyla güncel kalması önemlidir . Kodu, taban çizgisinden (veya uygulamaya bağlı olarak sürüm dalını) geliştirme dalınıza kadar birleştirmeniz gerekir. Bu sizin durumunuz için önemlidir, çünkü sürümü 1.4.8-SNAPSHOT olarak değiştiren serbest bırakma işlemi sırasında ortaya çıkan pom değişikliklerinin bu şubeye getirildiği anlamına gelir.

Yaptığım okumaya dayanarak (organizasyonumdaki süreçlerle birlikte), bu Maven sürümlerinin ve anlık görüntülerinin oldukça standart ve etkili bir kullanımı gibi görünüyor ve farklı dallarda tamamen bağlantısı kesilmiş sürüm numaralarını korumak yerine, bunu söylemek kolay herhangi bir 1.4.7-SNAPSHOT yapısının aslında 1.4.7 sürümünün hemen öncüsü olduğu. Alakalılar. Şunu söyleyebilirim ki, bu dallar arasında ileri geri birleşmiyorsan, hem SCM hem de Maven sürümlerini yanlış yapıyorsun ve üretime uymayan koda karşı gelişme riski taşıyorsun , hataları üretime yeniden tanıtır vb.

Yaklaşımınızı yeniden düşünün.

Örneğin sürüm 1.4 için 1.4.2 ve sonra bir sonraki geliştirme için 1.4.3-SNAPSHOT kullanımı çok yaygındır.

1.4.2 SONRA sürümünün bakımını yapmanız gerektiğinde, 1.4.2 eserinizi oluşturan taahhütten dallayın.

Ardından Jenkins'e deponuzun konumunu ve şube adını söylersiniz, bu da bir dosya kümesinin kullanıma alınmasına neden olur ve sonra Jenkins'e projenizi oluşturmak için maven'i kullanmasını söylersiniz.

Not: Müşteriye gitmek için gerçek parçaları oluşturmak için tek bir pom.xml ve başka bir pom.xml kullanmanın çok yararlı olduğunu gördüm.