Büyük organizasyonlarla branchageddon nasıl önlenir?

10

Büyük kuruluşlarla çalışırken branchageddon durumunu nasıl önlersiniz?

Yaklaşımı yazılım güncellemelerini değil, yalnızca yüksek / kritik güvenlik yamalarını ve ısmarlama işlevselliği almak olan bir dizi büyük finansal kuruluşla çalışıyoruz. Bu kuruluşlar yalnızca büyük güncellemeler arasında düzeltme ekleri ve özel sürüm alacaktır. Büyük güncellemeler yıllarca sürebilir ve yüksek maliyetler taşıyabilir. Bu yaklaşım, bize (yazılım evi) büyük müşteri başına kodumuzun bir şubesine sahip olmamıza neden olur, bu da uzun vadeli dallamanın tüm maliyetlerini ve verimsizliğini taşır.

Topluluğa sorularım:

Müşterilerinizden benzer güncelleme kabul yaklaşımları yaşadınız mı?
Bu yaklaşımla çalışmanıza yardımcı olacak önerileriniz nelerdir?
Kuruluşların yazılım güncellemeleri almaya yaklaşımlarını değiştirmeye yardımcı olacak önerileriniz nelerdir?

release process branch

— Mark Wheeler
kaynak

Hey Mark, ilginç bir ikileminiz var gibi görünüyor. Bunları müşteri başına güncelleme geliştirmeyi nasıl yönetiyorsunuz? Bunları her müşteri için bir defalık temel olarak mı geliştiriyorsunuz, yoksa geliştirdiğiniz ve tüm müşteriler için uyguladığınız bir şey mi?

— PrestonM

Şahsen, bu durumda başka istihdam arayabilirim. Bu, gerçekleşmeyi bekleyen bir güvenlik olayı gibi geliyor ... Size çalıştığım cihaz satıcısı için söyleyebilirim, bildirilemedikleri bir güncellemede düzeltilen büyük bir hata vardı. Özel bir düzeltme istiyorlardı. Bunlardan birini oluşturmayı reddettik ve onlara işletme politikalarını düzeltmeleri gerektiğini söyledik - dahili politik sorunlardan kaçınmaları için zaten yamaladığımız bir hata için özel bir düzeltme yapmayacağız.

— James Shewey

Özel istemciye özgü güncelleştirmeleri birden çok kod dalı ve tüm şubelere yönelik çapraz güvenlik güncelleştirmeleri ve şube kodunu yeniden gövdeye çapraz olarak yönetiyoruz. Genellikle A müşterisi şubelerinde B müşterisi güncellemelerini almayacak, sadece kendi güncellemelerini ve güvenlik yamalarını alacaktır. Bu, dallarındaki istikrar arzusundan kaynaklanmaktadır ve bu nedenle yalnızca kendileriyle ilgili güncellemeleri test etmek zorundadırlar. Komple test tekrarlarını çalıştırmaya hazır olduklarında, gövde güncellemelerini daha az sıklıkta (örneğin aylar-yıllar) alırlar, bu da tamamlanması aylar alabilir. Otomatik test cevap olabilir!

— Mark Wheeler

3

Michael'ın belirttiği gibi, endüstriniz için oldukça uzun bir kullanım süresine sahip sürüm sürümlerine / numaralarına dayanan standart bir çözüm sunun (tipik müşterileriniz için mantıklıysa, bir veya daha fazla kısa ömürlü ara sürümlerle serpiştirilebilir).

Müşterilerinize bu standart sürüm yoluna başlama seçeneği verin, belki de uygun bir son taşıma tarihi vardır.

Tam özel bir şube destek stratejisinde ısrar ediyorlarsa, bu tür tam özel destek sunmak için tüm ekstra maliyetlerinizi düzgün bir şekilde karşılamak için bunları uygun şekilde ücretlendirin - sadece iş anlamlıdır. Bazı müşteriler maliyetlerini düşürmek için (özel şube sayısını azaltmanıza yardımcı olacak) taşınır, bazıları yapmaz.

Özel şubelerin çıktığı sürümlerin yaşıyla birlikte giderek artan değişken destek faturalandırması, müşterilerin daha yeni şubelere daha hızlı geçiş yapmalarını teşvik ederek eski özel şubelerin daha hızlı kapanmasına da yardımcı olabilir. Bu, yazılımınızın birden çok sürümünü aynı anda çalıştıran müşterileriniz varsa, müşteri başına özel şube sayısının azaltılmasına yardımcı olabilir.

Serbest bırakma dallarından herhangi birine (hem standart hem de özel) tam dal birleşmeleri yapma tuzağına düşmediğinizden emin olun, bunlarda yapılan tüm değişiklikler ayrı ayrı geliştirilmiş veya kirazla toplanmış birleştirilmiş düzeltmeler olmalıdır.

Bu dalların her biri birbirinden kademeli olarak ayrıldığından, özelleştirme / bireysel geliştirme gerektiren düzeltme sayısı katlanarak artacaktır (düz kiraz toplama birleştirme başarısız olacaktır). Bunların geliştirme maliyetini dikkate almanız gerekir.

Resimde (önemli) hiçbir şube birleşmesi olmadan, bu şubeler için tam otomatik bir CI / CD boru hatları oluşturabilir, yerinde iyi bir düzeltme izleme / yönetim sistemi ile birlikte, düzeltme dağıtımını yapabilirsiniz sadece rutin (veya neredeyse).

— Dan Cornilescu
kaynak

Dan - çok açık ve basit ama mükemmel bir mantıklı. Para, dünyayı dolaşır ve uzun ömürlü dalların maliyetini telafi etmemize veya müşterileri geliştirmeye ve gövdeye yakın kalmaya teşvik etmeye yardımcı olur. İyi tavsiye için teşekkürler.

— Mark Wheeler

1

Belki müşteriler yerine sürümler başına şubeler tuttuysanız, sayılarını azaltmaya yardımcı olabilir?

Aksi takdirde, bundan gerçekten kurtulmanın tek yolu, yazılımı kendiniz barındırabilmeniz ve yalnızca bir sürümünü koruyabileceğiniz bir SaaS modeline geçebilmektir.

— Michael Pereira
kaynak

Maalesef müşterilerimiz, birlikte çalıştıkları finansal veriler nedeniyle genellikle çok kapalı ortamlarda çalışmaktadır, bu nedenle bir SaaS modeli kabul edilemez.

— Mark Wheeler