Not: Sorum belirli sorunuma odaklandı (Liferay'ı içeriyor), ancak umarım git üzerinde aynı projenin çeşitli sürümlerini tutması gereken herkes için yararlı olabilir.

Liferay Portal için birçok eklenti yazan bir şirkette çalışıyorum . Bu eklentiler (portletler, temalar vb.) Genellikle yeniden kullanılabilir ve elbette portalın yeni sürümleri için güncellenmelidir.

Ancak, taşınamayacak kadar var bize, demek Liferay yeni sürümüne portlet izin olağandır ve önceki sürümü korumak için. Ayrıca, sık sık bazı istemciler için çok özel özelleştirmeler oluşturmak zorundayız.

Bu gereklilikler işimizi karmaşıklaştırıyor, ancak neyse ki bazı basitleştirmeler yapabiliriz. Örneğin, eklentiler bir seferde yalnızca bir programcı tarafından sık sık güncellenir. Bir eklentiye aynı anda iki veya daha fazla özelliğin eklenmesi çok nadirdir.

Şimdi Gitorious'a göç ediyoruz . Böyle bir senaryo için bir dallanma modeli tasarlamaya çalışıyoruz.

Benim modelim

Ne önerdi:

1. Her eklenti bir proje içinde Gitorious'da kendi deposuna sahip olacaktı. Örneğin, yavru kedileri sergilemek için bir portletin proje kittens-portletiçinde bir deposu olacaktır liferay-portlets.
2. Yeni bir eklenti oluştururken, Liferay sürümüne göre adlandırılmış bir dalda oluşturun (örneğin, lf5.2).
3. Eklenti üzerinde her güncelleme yapıldığında, güncelleme onaylanır ve üretimde dağıtılır, eklentiyi bir sürümle etiketleyin (örneğin lf5.2v1, lf5.2v2vb.) *
4. Bir eklentinin Liferay'ın yeni bir sürümüne her taşınması gerektiğinde, en son sürümü dallıyoruz (örneğin, dalı yaratıyoruz lf6.0).
5. Üretime girdikten sonra, yeni şubenin başı gibi bir etiket alacak lf6.0v1.
6. Bir eklentiyi istemciye özgü bir şekilde özelleştirmek istediğimizde, istemcinin adıyla bir şube oluştururuz (örneğin, lf5.2clientcorpmüşterimiz "ClientCorp Inc." için bir şube oluştururuz )

Bu alışılmadık bir model: masterbirleşmeyen ve çok fazla şubesi olmayacaktı. Ben böyle bir model ile bir havuz gibi görüneceğini varsayalım :

Bir arkadaş bu sistemi oldukça karmaşık ve hataya açık buldu. Yönetmek ve disiplin talep etmek için hala zor bulduğum mükemmel ve popüler Vincent Driessen modelini önerdi . Elbette harika (ve test edildi!) Ama durumumuz için çok karmaşık görünüyor.

Arkadaşımın modeli

Sonra başka bir model önerdi: Liferay versiyonundaki her eklenti için bir havuzumuz olurdu (böylece her biri bir dal ve bir dalı olan bir kittens-lf5.2-portletve sonra a oluşturmaya başlayacağız kittens-lf6.0-portlet) . Her zaman dağıtım için hazır olacaktır. (Ya da tersi olması, olabilir ve önerdiği gibi, Steve Losh ).masterdevelopmastermasterstable

Bu çok basit, ama bu sistemi beğenmedim:

1. bir projede çok fazla depoya neden olabilir ve bu da Gitorious'u taramayı zorlaştırır.
2. Proje dizininin adı önemlidir. Birisi deposu bir kittens-lf6.0-portletdizine kopyalar ve WAR'u karınca (her zamanki gibi) ile üretirse, WAR adı da olacaktır kittens-lf6.0-portlet. Bu portletin eski sürümleri ( kittens-portletörneğin adlandırılmış ), yükseltilmiş bir portaldaki farklı (ve muhtemelen eksik) portletler olarak kabul edilir. Biraz bakım bundan kaçınabilir ama kaçınmayı tercih ederim.
3. Aynı eklentinin farklı sürümleri ayrı tutulur. Kalbimi kırıyorum :(
4. kittens-lf6.0-portlet bence bir depo için çirkin bir isim.

Son iki noktanın - ki bunlar da daha öznel olan iki noktayı - isteksizliğimin ana nedeni olduğunu düşünüyorum. Bununla birlikte, dört itiraz da geçerlidir.

OTOH, kendi teklifim kendime garip geliyor ve üzerinde gizli böcek olup olmadığını merak ediyorum. OT3rdH git o kadar güçlü ve esnek ki, olasılıklarını keşfetmekten utanmamam gerektiğini düşünüyorum.

Yani soruyorum:

1. En iyi model ne olurdu? Teklifim mi? Arkadaşımın modeli? Şimdi geleneksel Vincent Driessen sistemi?
2. Başka hangi dallanma modelini önerirsiniz?
3. Modelimin kötü olduğunu düşünüyorsanız neden böyle düşünüyorsunuz? Dezavantajların ve kör noktaların ne olduğunu öğrenmek isterim.

* Aslında, taahhüt gibi bir sürümü ile etiketlemek tercih ederdim v1ama görünüşe göre git bir etiket şube kapsamı içinde değildir - yani, ben 1 v1etiketi lf5.2ve başka bir etiket olamazdı lf6.0- bu yüzden isim vermek zorunda dalı. BTW doğru mu?

Bunu düzgün bir şekilde okursam, dallar temel olarak ana gelişim çizginizden tek adımlık bir sapmadır, asla ana hatta geri birleştirilmeyi amaçlamaz ve ana hattaki ilerlemeler asla bu dallara uygulanmaz. Tek sapma, dalın dayandığı sürüme uygun hata düzeltmelerinin dalda uygulanması gerektiğidir.

Cevap şimdi günlük iş akışınızda dönüyor, herhangi bir dalda çalışan geliştirici sayısı veya değişiklik sayısı kırmızı sürülerdir. Birincil ihtiyacınızı, ana dal değişikliğinden hangi dalların hata düzeltme güncellemesi aldığını bilmek istemek olarak görüyorum ve bunun için şubelerle birleştirilmiş havuzun hepsi tek bir yerde olduğundan daha verimli olacağını düşünüyorum. Çapraz tozlaşmaya hiç ihtiyaç duyulmamış olsaydı, ayrı depolar bunu zorlardı, ancak bu senaryo, anladığım kadarıyla projenizin gerçekliğine uymuyor.

Projenizin şubeleri ana geliştirme hattına dönüştürmesi gerekiyorsa, Driessen modeli iyi çalışır, ancak buna ihtiyacınız yoktur. Yine de, canlı bir ürün üzerinde çalışıyorsanız, InDevelopment ve StableRelease konseptini korumanın bir faydası olduğunu düşünüyorum.

Özetlemek gerekirse, projenizin dallanma modeliniz ve ana hattınız için bir dizi Driessen ile iyi çalışacağını düşünüyorum. Kilometreniz değişebilir; Ben her zaman bir "canlı" dalı dönüşür "beklemede serbest bırakma" dalı ve tüm algılamaları önyargılı olabilir böylece çeşitli noktalarda düzeltmeler ve değişiklikler çapraz tozlaşma gerektiren ayrı bir "sonraki sürümü" ile çalıştım.

Beni zorlayan şey, her portletin kendi deposuna sahip olması (ancak hikayeniz tam olmayabilir). Şahsen ben proje başına bir depo oluşturacağım. Projeler genellikle birden çok portlete sahiptir ve aynı Liferay sürümüne karşı aynı çalışmada oluşturulur. Her proje, Liferay'ın farklı bir sürümüne göre oluşturulmuş mevcut bir projenin kopyası olabilir, ancak bir ürünü yalnızca farklılıklar çok büyükse bölebilirim. Eğer bir yapı Liferay 5.1 ve 5.2'ye karşı çalışırsa projeyi bölmezdim. Her şeyin çalışmasına izin vermek için komut dosyası veya Maven (veya her ikisini) kullanırdım. Her ürünün yönetimi ve Liferay'ın hangi sürümüne karşı oluşturulabileceği için bir Wiki (veya Trello) kullanırdım.

Bu arada: Ben bir Java programcısıyım, Maven uzmanıyım, Build uzmanıyım ve Liferay ve diğer portal sunucuları (IBM WebSphere ve Glassfish) konusunda deneyimim var.

Ama bu sadece benim 0,02 €.