Sürekli entegrasyonda birden çok şubeyi yönetme

Question 1

Şirketimde CI ölçeklendirme sorunuyla uğraşıyorum ve aynı zamanda CI ve birden çok şubeye gelince hangi yaklaşımı benimsemeye çalışıyorum. Stackoverflow, Çoklu özellik dalları ve sürekli entegrasyonda benzer bir soru var . Yeni bir tanesine başladım çünkü daha fazla tartışma yapmak ve soruda bazı analizler yapmak istiyorum.

Şimdiye kadar, alabileceğim 2 ana yaklaşım olduğunu (veya belki başka bazılarını ???) buldum.

Dal başına birden fazla iş kümesi (burada Jenkins / Hudson'dan bahsediyoruz)
- Ekstra işleri yönetmek için araçlar yazın
  - İşleri toplu olarak oluşturma / değiştirme / silme
  - Dal başına her iş için özel ayarlar (SCM url, dep yönetimi depo kopyaları)
  - Kabuk araçları, karınca betikleri ve Jenkins CLI ile bu sorunu çözen insanlara bazı örnekler. Görmek:
- CI kümenizde daha fazla yüke neden olur
- Geliştiriciler için geri bildirim döngüsü yavaşlıyor (altyapı yeni yükü kaldıramıyorsa)
2 şube başına birden çok iş kümesi (geliştirme ve kararlı)
- İki grubu manuel olarak yönetin (bir işin yapılandırmasını değiştirirseniz, diğer dalda da değiştirdiğinizden emin olun)
  - PITA ama en azından yönetilmesi gereken çok az
- Diğer ekstra dallar, geliştirmeye gönderilmeden önce tam bir test paketi alamaz
- Memnun olmayan geliştiriciler. CI ölçeklendirme sorunları neden bir geliştirici tarafından dikkate alınmalıdır? Basit bir isteği var, şubeye gittiğimde kodumu test etmek istiyorum. Basit.

Görünüşe göre geliştiricilere kendi özel dalları için CI sağlamak istiyorsam, Jenkins için özel araçlara ihtiyacım var (API veya kabuk komut dosyaları veya başka bir şey?) Ve ölçeklendirmeyi halledebilirim. Veya onlara DEV ile daha sık birleşmelerini ve özel şubelerde CI olmadan yaşamalarını söyleyebilirim. Hangisini tercih edersiniz yoksa başka seçenekler var mı?

Question 2

CI'yi ölçeklendirmekten bahsettiğinizde, tüm özellik dallarınızı ana hattınızla birlikte idare etmek için CI sunucunuzun kullanımını ölçeklendirmekten gerçekten bahsediyorsunuz. Başlangıçta, bir şubedeki geliştiriciler CI işlerinin içerdiği otomatik testin tüm avantajlarını elde ettikleri için bu iyi bir yaklaşım gibi görünüyor. Ancak, CI sunucu işlerini yönetirken sorunlarla karşılaşırsınız (keşfettiğiniz gibi) ve daha da önemlisi, gerçekten CI yapmıyorsunuz. Evet, bir CI sunucusu kullanıyorsunuz, ancak tüm geliştiricilerinizin kodunu sürekli olarak entegre etmiyorsunuz.

Gerçek CI gerçekleştirmek, tüm geliştiricilerinizin ana hatta düzenli olarak taahhütte bulunduğu anlamına gelir. Söylemesi kolay, ancak işin zor kısmı uygulamanızı bozmadan bunu yapmaktır. Sürekli Teslime , özellikle Bölüm 13: Bileşenleri ve Bağımlılıkları Yönetme'deki Uygulamanızı Yayınlanabilir Tutma bölümüne bakmanızı şiddetle tavsiye ederim . Ana noktalar:

Tamamlanana kadar yeni işlevi gizleyin (AKA Feature Toggles ).

Tüm değişiklikleri, her biri serbest bırakılabilen bir dizi küçük değişiklik olarak aşamalı olarak yapın.

Kod tabanında büyük ölçekli değişiklikler yapmak için soyutlama yoluyla dalı kullanın.

Uygulamanızın farklı hızlarda değişen parçalarını ayırmak için bileşenleri kullanın.

Soyutlamayla dallanma dışında oldukça açıklayıcıdırlar. Bu sadece şunun için süslü bir terimdir:

Sistemin değiştirmeniz gereken kısmı üzerinde bir soyutlama oluşturun.

Soyutlama katmanını kullanmak için sistemin geri kalanını yeniden düzenleyin.

Tamamlanana kadar üretim kodu yolunun parçası olmayan yeni bir uygulama oluşturun.

Yeni uygulamanıza yetki vermek için soyutlama katmanınızı güncelleyin.

Eski uygulamayı kaldırın.

Artık uygun değilse soyutlama katmanını kaldırın.

Bölüm 14: Gelişmiş Sürüm Kontrolü'ndeki Dallar, Akışlar ve Sürekli Entegrasyon bölümündeki aşağıdaki paragraf , etkileri özetlemektedir.

Aşamalı yaklaşım, bir şube oluşturmaktan ve yeniden tasarlama ve yeni işlevsellik geliştirmeye hevesli bir şekilde dalmaktan kesinlikle daha fazla disiplin ve özen ve aslında daha fazla yaratıcılık gerektirir. Ancak değişikliklerinizin uygulamayı bozma riskini önemli ölçüde azaltır ve sizin ve ekibinizin birleştirme, kırılmaları düzeltme ve uygulamanızı konuşlandırılabilir bir duruma getirme konusunda önemli ölçüde zaman kazandıracaktır.

Özellik dallarından vazgeçmek oldukça zihinsel bir değişim gerektirir ve her zaman dirençle karşılaşırsınız. Tecrübelerime göre bu direnç, geliştiricilerin ana hattı kodlama konusunda kendilerini güvende hissetmemelerine dayanıyor ve bu makul bir endişedir. Bu da genellikle yukarıda listelenen tekniklerle ilgili bilgi, güven veya deneyim eksikliğinden ve muhtemelen otomatik testlerinize olan güven eksikliğinden kaynaklanır. İlki, eğitim ve geliştirici desteği ile çözülebilir. İkincisi, uğraşması çok daha zor bir sorundur, ancak dallanma ekstra gerçek bir güvenlik sağlamaz, sadece geliştiriciler kodlarına yeterince güvenene kadar sorunu erteler.

Question 3

Her şube için ayrı işler kurardım. Bunu daha önce yaptım ve Hudson / Jenkins'i doğru bir şekilde kurduysanız yönetimi ve kurulumu zor değil. Birden çok iş oluşturmanın hızlı bir yolu, benzer gereksinimleri olan mevcut bir işten kopyalamak ve gerektiğinde bunları değiştirmektir. Her geliştiricinin kendi şubeleri için kendi işlerini kurmasına izin vermek isteyip istemediğinizden emin değilim, ancak bu bir kişinin (yani bir yapı yöneticisi) yönetmesi için fazla bir iş değil. Özel dallar kararlı dallar halinde birleştirildikten sonra, karşılık gelen işler artık gerekli olmadığında kaldırılabilir.

CI sunucusundaki yükten endişeleniyorsanız, yükü birden çok sunucu arasında dengelemeye yardımcı olmak için ayrı CI örnekleri veya hatta ayrı bağımlı birimler kurabilirsiniz. Hudson / Jenkins'i çalıştırdığınız sunucunun yeterli olduğundan emin olun. Apache Tomcat kullandım ve derleme kuyruğunu işlemek için yeterli belleğe ve işlem gücüne sahip olduğundan emin olmam gerekiyordu.

CI kullanarak neyi başarmak istediğiniz konusunda net olmak ve daha sonra çok fazla manuel çaba veya tekrarlama olmadan bunu uygulamanın bir yolunu bulmak önemlidir. CI sunucunuz tarafından yürütülen ve genel yapı yönetimi sürecinizi basitleştirmeye yardımcı olan diğer harici araçları veya komut dosyalarını kullanmakta yanlış bir şey yoktur.

Question 4

Dev + kararlı dalları seçerdim. Ve hala özel dallar istiyorsanız ve yükten korkuyorsanız, neden bu özel dalları buluta taşımıyorsunuz ve geliştiricilerin bunu kendilerinin yönetmesine izin vermiyorsunuz, örneğin http://cloudbees.com/dev.cb Bu, Kohsuke'nin bulunduğu şirkettir. . Ayrıca bir Eclipse Tooling de vardır, bu nedenle Eclipse üzerindeyseniz, onu doğrudan geliştirme ortamına sıkıca entegre etmiş olursunuz.

Question 5

Aslında gerçekten sorunlu olan şey, özellik dalları ile yalıtım oluşturmaktır. Şirketimizde, tümü daha büyük bir dağıtımın parçası olan bir dizi ayrı maven projemiz var. Bu projeler farklı ekipler tarafından sürdürülür, ancak her dağıtım için tüm projelerin yayınlanması gerekir. Bir özellik dalı artık bir projeden diğerine örtüşebilir ve bu, inşa izolasyonu acı verici bir şekilde olduğunda bu olur. Denediğimiz birkaç çözüm var:

her özellik dalı için bağlantı noktasında ayrı anlık görüntü havuzları oluşturun
özel slave'lerde yerel depoları paylaşın
havuz-sunucu-eklentisini yukarı akış havuzlarıyla birlikte kullanın
tek bir özel depo ile tek bir iş içinde oluşturun

Nitekim son çözüm en umut verici olandır. Diğer tüm çözümler şu veya bu şekilde eksiktir. Job-dsl eklentisi ile birlikte yeni bir özellik dalı kurmak kolaydır. sadece harika komut dosyasını kopyalayıp yapıştırın, dalları uyarlayın ve tohum işinin yeni işleri oluşturmasına izin verin. Başlangıç işinin yönetilmeyen işleri kaldırdığından emin olun. Ardından, farklı maven projeleri üzerinde özellik dalları ile kolayca ölçeklendirebilirsiniz.

Ancak Tom'un yukarıda da söylediği gibi, özellik dallarının gerekliliğinin üstesinden gelmek ve geliştiricilere temiz bir şekilde entegre olmayı öğretmek daha iyi olurdu, ancak bu daha uzun bir süreç ve artık dokunmayacağınız birçok eski sistem parçasıyla sonuç net değil.

benim 2 sentim