Müşteriye özel yazılım yamalarını işlemenin gerçekçi bir yolu nedir?

Başkalarının aşağıdaki sorunu çözdüğü etkili yolları toplamaya çalışıyorum. İş yerinde, yalnızca belirli bir müşterinin görmesini istediğimiz bir yazılım yamasını (son kullanıcı sistemlerine yüklenecek) yayınlamak zorunda kaldık. Özel kod kendi kaynak denetim dalındadır. Sorun, senkronize olmasını sağlamak için iki paralel kod satırımız (ve komut dosyaları oluşturmamız) ve orijinal kodu her eklediğimizde müşteriye özel kodu yamalamamız ve test etmemiz gerekiyor.

Merak ediyorum, diğer kuruluşlar bu senaryoyu nasıl ele alıyor? Biz sadece teknik (kaynak kontrolü ile ilgili) çözümlere değil, iş çözümlerine de açığız . Örneğin, müşteriye o dalda güncelleme alamayacaklarını söylemekten bahsettik.

Dallanma stratejimiz şu şekildedir (bunun için Subversion'ı kullanmamıza rağmen , Visual Studio TFS Dallanma Kılavuzu'na dayanmaktadır )

Müşteriye özel yamalar vermeye başladığınızda, ürününüzün hemen yanında tutulması gereken yeni bir sürümünü oluşturdunuz. Bu, değişikliklerin iki versiyon arasında yayılması gerektiği anlamına gelir. Genellikle müşteriye özel yamalar, kaynak kodu da dahil olmak üzere müşteriye ait olması gereken özelleştirmelerdir.

Bir yama olası görünüyor düzeltme bu acil sorun için daha az optimum geçici düzeltme daha olmadıkça bir şeye ana hat şube yapmak olmaz. Durum buysa, yamanın yalnızca beklenen düzeltme ana hatta gelinceye kadar korunması gerekir.

Bana öyle geliyor ki anahtar "görünür" - ayrı bir kod dalı olmamasına değil, davranışı değiştiren bir yapılandırma seçeneğine ne dersiniz?

Bunu kısa vadeli veya uzun vadeli bir şey olarak görüyor musunuz? Gerçek şu ki, işletme zaten bu müşteriyi bu kadar kısa vadede barındırmaya karar vermiştir, zaten iş uygulamaları tarafından çözülmesi gereken bir iş kararıdır (ekstra maliyeti kabul etmek / müşteriye maliyet almak).

Uzun vadede, yazılımın müşterilerin yapılandırma (veya kurulum vb.) Aracılığıyla gereksinimlerini kolayca karşılamak için yeniden çarpanlarına ayırırsanız büyük olasılıkla tasarruf göreceksiniz.

Nispeten kısa vadeli bir anlam taşıyorsa, bu değişiklikleri kısa bir süre sonra ana / geliştirme dalında birleştireceksiniz ve tüm kullanıcılar değişiklikleri de görecek, o zaman mevcut durumunuzun sınırları dahilinde çalışmak kabul edilebilir olacaktır. Dediğim gibi, müşteriyi kabul etme kararı verildiğinde ne yapılması gerektiğine karar verilmesi gerekiyordu.

Uzun lafın kısası. Uzun vadeli teknik olarak düzeltmek, Kısa vadeli anlaşma.

Tabii ki bir madalyonun attığı bir nokta var. Eğer bu noktadaysanız geliştiricilerin tercih ettiği her şeyi yaparım.

Yıkımı da kullanıyoruz - ve tam olarak böyle bir senaryo ile karşılaşıyoruz.

Unutmamanız gereken bazı önemli noktalar şunlardır:

1. Gerekli olsa da, müşteriler için belirli şubelerden kaçınılmalıdır, ihtiyaç mümkün olduğunca en aza indirilmelidir; her zaman işe yarayabilecek çözümü genelleştirmenin mümkün olup olmadığını her zaman sorun.

2. Müşteriye özel şubeler yeni bir sürümden kaynaklanmalıdır. 1.2 sürümüne sahip olduğunuzu ve 1.2.1 sürümünden 1.2.11 sürümüne kadar türettiğinizi varsayalım - müşteri şubelerinin tüm yamalara izin vermesi gerekir, bu nedenle müşteri şubesinin ana sürüme göre uyumlu kalması gerekir .

3. Uyumlu olmayan yeni bir sürüm başlattığınızda müşteriye özel bir şube oluşturmalısınız. Talihsiz kısım, bir şekilde yeniden yapmanız gerekebileceğidir işi . Çözümlerden biri, müşteri şubelerinden tüm yamaların çıkarılması gerektiğidir ve hala uyumlu olan her şey yeni müşteri şubesine uygulanabilir.

4. Her zaman, hiçbir koşulda, şube veya bagajı serbest bırakmak için müşteriye özgü değişiklikleri geri göndermemelisiniz. Bununla birlikte, ideal olarak, çalışma, müşteriye özel bu tür çalışmaların azaltılacağı şekilde genelleştirilmeye çalışılmalıdır.

Bu fikri göstermek için bir araya getirmeye çalıştım :

Kodunuza bir uzatma mekanizması eklemeye ne dersiniz?

Ana kodunuz:

class Foo
{
}

Program başlatıldığında, başlangıç ​​klasöründe yerel özelleştirmeler için DLL / ahlaki eşdeğerini kontrol eder. Birini bulursa yüklenir ve Foo'nun şirkete özel sürümünü içerebilir

class FooForABC : Foo
{
}

FooForABC, Foo ile aynı davranışı uygular, ancak ABC'nin ihtiyaç duyduğu belirli davranışı sağlamak için gereken işlevleri geçersiz kılar. Teknik, desteklemeniz gereken herhangi bir senaryoyu işleyebilecek kadar esnek olmalıdır.