Ana şubede yüzlerce özelleştirilmiş şubenin bakımını yapın

Şu anda paylaşılan bir depoda PHP uygulamamız için bir ana şubemiz var. Her biri ayrı bir branşta farklı amaçlarla kişiselleştirilebilen, yazılımımızın abonesi olan 500'den fazla müşterimiz var. Özelleştirme, farklı bir metin alanı adı, tamamen yeni bir özellik veya modül veya veritabanındaki yeni tablolar / sütunlar olabilir.

Karşılaştığımız zorluk, bu yüzlerce kişiselleştirilmiş şubeyi koruduğumuz ve müşterilere dağıttığımızdan, zaman zaman yeni özellikler sağlayıp ana şubemizi güncellediğimiz ve ana şube değişikliklerini güncellemek için özel şubelere itmek istiyoruz. Onları en son sürüme.

Ne yazık ki, bu genellikle özel kodda birçok ihtilafla sonuçlanır ve tüm ihtilafları çözmek için her daldan birkaç saat geçiririz. Bu çok verimsiz ve bu çatışmaları çözerken hataların nadir olmadığını gördük.

Birleşme sırasında daha az çaba harcayacak ana şubeyle müşteri yayın şubelerimizi güncel tutmak için daha verimli bir yol arıyorum.

Tamamen kötüye kullanıyorsun! Özelleştirmeye sahip olmanız, uygulamanızdaki esneklikle güçlendirilmeli, sürüm kontrolünüzdeki esneklik olmamalıdır (keşfettiğiniz gibi bu kullanım için tasarlanmamış / tasarlanmamıştır).

Örneğin, metin alanı etiketlerinin bir metin dosyasından gelmesini sağlayın, uygulamanıza kodlanmamış (bu şekilde uluslararasılaştırma nasıl işler). Bazı müşterilerin farklı özellikleri varsa, uygulamanızı sıkı ve kararlı API'lerin yönettiği katı iç sınırlarla modüler hale getirin , böylece özellikler gerektiği gibi takılabilir.

Temel altyapı ve paylaşılan özelliklerin daha sonra yalnızca bir kez saklanması, bakımı ve test edilmesi gerekir .

Bunu baştan yapmalıydın. Zaten beş yüz ürün çeşidiniz (!) Varsa, bunu düzeltmek çok büyük bir iş olacak… ama devam eden bakımdan daha fazlası değil.

500 müşteriye sahip olmak güzel bir sorundur, şubelerdeki bu sorunu önlemek için vaktinizi harcadıysanız, müşterileri alacak kadar uzun süre ticaret yapamayacaksınız.

Öncelikle, müşterilerinizden TÜM özel sürümlerini koruma maliyetlerini TÜM karşılayacak kadar ücretlendirmenizi umarım . Müşterilerin, özelleştirmelerinin yeniden yapılması için ödeme yapmak zorunda kalmadan yeni sürümler almayı beklediklerini tahmin ediyorum. Şubelerinizin% 95'inde aynı olan tüm dosyaları bularak başlardım. Bu% 95'i uygulamanızın istikrarlı bir parçasıdır.

Ardından, dallar arasında yalnızca birkaç satır bulunan tüm dosyaları bulun - bu farklılıkların giderilebileceği bir yapılandırma sistemi sunmaya çalışın. Örneğin, farklı metin alanı etiketli 100'lerce dosyaya sahip olmak yerine, herhangi bir metin etiketini geçersiz kılan 1 yapılandırma dosyanız var. (Bu tek seferde yapılmak zorunda değildir, sadece müşteriyi ilk kez değiştirmek istediğinde yapılandırılabilir bir metin alanı etiketi hazırlayın.)

Ardından, Strateji modelini, bağımlılık enjeksiyonunu vb. Kullanarak daha zor konulara geçin.

Müşterinin kendi alanlarına sütunlar eklemek yerine, json'u veritabanında saklamayı düşünün; bu alanları SQL ile aramanız gerekmiyorsa bu sizin için işe yarayabilir.

Bir dosyayı bir şubeye ne zaman kontrol ederseniz, onu ana dosyaya bölmeli ve beyaz boşluk dahil her bir değişikliği doğrulamanız GEREKİR. Birçok değişiklik gerekli olmayacak ve check-in işleminden önce kaldırılabilir. Bu, kodun nasıl biçimlendirildiğiyle ilgili olarak editöründe farklı ayarlara sahip olan bir geliştiriciye bağlı olabilir.

Öncelikle, birçok farklı dosyaya sahip 500 şubeden, birçok farklı dosyaya sahip sadece birkaç şubeye gitmeyi hedefliyorsunuz. Hala yaşamak için yeterince para kazanırken.

Uzun yıllar boyunca hala 500 şubeniz olabilir, ancak yönetimi çok daha kolaysa, o zaman kazandınız.

Br3w5 tarafından yapılan yoruma göre:

• Müşteriler arasında farklı olan her bir sınıfı alabilirsin
• Sınıfta çağrılan tüm yöntemleri dıştan tanımlayan bir “xxx_baseclass” yapın.
• Sınıfı, xxx'in xxx_clientName (xxx_baseclass'ın alt sınıfı olarak) olarak adlandırılması için yeniden adlandırın.
• Bağımlılık enjeksiyonunu kullanın, böylece sınıfın doğru sürümü her müşteri için kullanılır.
• Ve şimdi zekice bir anlayış için br3w5 geldi! Şimdi kopyalanan kodu bulmak için statik bir kod analiz aracı kullanın ve onu vb. Temel sınıfa taşıyın.

Yukarıdakileri sadece kolay tahılın elde edilmesinden sonra yapın ve ilk önce birkaç sınıfa koyun.

Gelecekte, röportajınızda Joel test sorularını sorun. Bir tren kazasına girmemeniz daha muhtemel.

Bu bir ah, nasıl diyelim ... gerçekten, gerçekten kötü bir problem. Bu teknik borç üzerindeki "faiz oranı" çok, çok yüksek olacak. Kurtarılabilir olmayabilir ...

Bu özel değişiklikler "çekirdek" ile nasıl bütünleşir? Onları kendi kütüphaneleri haline getirip tek bir "çekirdeğe" ve kendi "eklentisine" sahip her bir müşteriye sahip olabilir misiniz?

Yoksa bunların hepsi çok küçük konfigürasyonlar mı?

Çözümün bir birleşimi olduğunu düşünüyorum:

• Tüm kodlanmış değişiklikleri konfigürasyon tabanlı öğelere dönüştürmek. Bu durumda herkes aynı temel uygulamaya sahiptir, ancak kullanıcılar (veya siz) işlevselliği açar / kapatır, adlandırmaları vb.
• Projeleri ayırmak için "müşteriye özel" işlevselliği / modülleri taşımak, böylece bir "proje" yerine, kolayca ekleyebileceğiniz / çıkarabileceğiniz modüller içeren bir "temel proje" ye sahip olursunuz. Alternatif olarak, bu yapılandırma seçeneklerini de yapabilirsiniz.

500'den fazla müşteriyle burada sona ermeymiş gibi önemsiz de olmayacaksınız, muhtemelen bu konuda gerçek bir ayrım yapmadınız. Bunun ayrılmasındaki değişikliklerin çok zaman alan bir iş olacağını umuyorum.

Ayrıca müşteriye özel tüm kodunuzu kolayca ayırıp kategorilere ayırmakta ciddi sorunlar yaşayacağınızdan şüpheleniyorum.

Yaptığınız değişikliklerin çoğu özel olarak farklılıklar gösteriyorsa, dil yerelleştirmeyle ilgili bu gibi soruları okumanızı öneririm . İster tamamen birden fazla dilde, ister sadece bir alt küme yapıyor olun, çözüm aynıdır. Bu özellikle PHP ve yerelleştirme.

Bu, herhangi bir VCS ile vurabileceğiniz en kötü anti-paternlerden biridir.

Buradaki doğru yaklaşım, özel kodu yapılandırma tarafından yönlendirilen bir şeye dönüştürmektir ve daha sonra her müşteri, bir yapılandırma dosyasında kodlanmış veya bir veritabanında veya başka bir yerde kendi koduna sahip olabilir. Tüm özellikleri etkinleştirebilir veya devre dışı bırakabilir, yanıtların görünümlerini ve benzeri şeyleri özelleştirebilirsiniz.

Bu, bir ana dalı üretim kodunuzla birlikte saklamanıza izin verir.

Şubelerin amacı, ana şubenin istikrarını bozma riski olmadan olası bir gelişme yolunu keşfetmektir. Sonunda uygun bir zamanda tekrar birleştirilmeleri veya çıkmaza neden olmaları durumunda atılmaları gerekir. Sahip olduklarınız çok fazla dal değil , aynı projenin 500 çatalı ve hayati değişiklik setlerini hepsine uygulamaya çalışmak bir sakat işi.

Bunun yerine, yapmanız gereken, temel kodunuzun kendi deposunda canlı hale getirmesidir, yapılandırma yoluyla davranışı değiştirmek ve ters bağımlılıkların izin verdiği şekilde davranışı enjekte etmek için gerekli giriş noktaları vardır .

Müşteriler için sahip olduğunuz farklı kurulumlar daha sonra birbirlerini yalnızca harici olarak yapılandırılmış durumlardan (örneğin bir veritabanı) ayırt edebilir veya gerekirse çekirdeği bir alt modül olarak ekleyen ayrı depolar olarak yaşayabilir.

Tüm önemli şeyler burada iyi cevaplarla önerilmiştir. Beş pence işlem önerisi olarak eklemek istiyorum.

Bu problemi uzun veya orta vadeli bir aralıkta çözmenizi ve politikanızı, nasıl kod geliştireceğinizi kabul etmenizi öneririm. Esnek bir öğrenme ekibi olmaya çalışın. Birisi yazılımı yapılandırılabilir yapmak yerine 500 repo alabiliyorsa, şimdiye kadar nasıl çalıştığınızı ve bundan sonra ne yapacağınızı kendinize sormanın zamanı gelmiştir.

Bunun anlamı:

1. Değişim yönetimi sorumluluklarını belirleme: Bir müşterinin bazı uyarlamalar, ihtiyacı varsa bunları satan, bunları sağlayan ve kim kod değişecektir nasıl karar verir? Bazı şeylerin değişmesi gerekiyorsa döndürülecek vidalar nerede?
2. Ekibinizde kimlerin yeni repolar yapmasına izin verilen ve kimin vermeyeceği rolünü netleştirin .
3. Takımınızdaki herkesin yazılım esnekliği sağlayan kalıpların gerekliliğini gördüğünden emin olmaya çalışın.
4. Yönetim aracınızı netleştirin: hangi müşterinin hangi kod kullanımına sahip olduğunu çabucak nasıl biliyorsunuz? Biliyorum, bazı "500 listesi" can sıkıcı geliyor, ama eğer istersen, işte bazı "duygusal ekonomi". Müşterinin hızlı bir şekilde değişikliklerini söyleyemezseniz, bir liste başlatmak zorunda gibi hissettiğinizde daha da kaybolmuş ve çizilmiş hissedersiniz. Ardından, özellikleri burada diğer kişilerin yanıtlarının size gösterdiği şekilde gruplamak için kullanın:
   • müşterileri küçük / büyük değişikliklere göre gruplandırmak
   • konu ile ilgili değişikliklere göre gruplama
   • birleştirilmesi kolay ve birleştirilmesi zor olan değişiklikleri gruplandırın
   • birkaç depoda yapılan eşit değişiklik gruplarını bulun (ah evet, bazıları olacak).
   • Yöneticinizle / yatırımcınızla konuşmak için belki de en önemlisi: Pahalı ve ucuz değişikliklere göre gruplandırmak .

Bu, hiçbir şekilde ekibinizde kötü bir atmosfer yaratacak şekilde değildir. Öncelikle kendiniz için bu noktaları açıklığa kavuşturmanızı ve desteğini hissettiğiniz her yerde, ekibinizle birlikte düzenlemenizi öneririm. Tüm deneyiminizi geliştirmek için masaya dost insanları davet edin.

Ardından, bu şeyi küçük bir alevde pişireceğiniz uzun süreli bir zaman penceresi oluşturmaya çalışın. Öneri: her hafta en az iki depoyu birleştirmeye çalışın ve en az bir tanesini kaldırın . Bunu sık sık öğrenebilir, rutin ve gözetim altında kaldığınız için ikiden fazla dalı birleştirebilirsiniz. Bu şekilde, bir yılda en kötü (en pahalı?) Şubelerle uğraşabilirsiniz ve iki yıl içinde bu sorunu daha iyi bir yazılıma sahip olacak şekilde azaltabilirsiniz. Ama daha fazlasını beklemeyin, çünkü sonunda bunun için "zamanınız olmayacak", ancak yazılım mimarı olduğunuz sürece artık buna izin vermeyeceksiniz.

Senin pozisyonunda olsaydım, bu şekilde üstesinden gelmeye çalışırdım. Bununla birlikte, ekibinizin bu tür şeyleri nasıl kabul edeceğini, yazılımın gerçekten buna nasıl izin verdiğini, nasıl desteklendiğinizi ve hala ne öğrenmek zorunda olduğunuzu bilmiyorum. Siz yazılım mimarısınız - sadece bunun için gidin :-)

Tüm nay-söyleyicilerle zıt olarak, gerçek iş ihtiyacını varsayalım.

(örneğin, teslim edilebilirlik kaynak kodudur, müşteriler aynı iş kolundandır ve bu nedenle birbirleriyle yarışırlar ve iş modeli sırlarını gizli tutmaya söz verir)

Ayrıca, şirketinizin tüm dallarını korumak için araçlara sahip olduğunu varsayalım, yani ya insangücü (diyelim 100 geliştiriciler birleştirme adanmış, 5 günlük bırakma gecikmesini varsayarak; veya 10 devs varsayarak 50 günlük sürede gecikme Tamam olduğu) veya otomatik birleştirmeleri gerçekten hem test edilir böyle müthiş otomatik test çekirdek spec ve uzatma spec her dalında ve "temiz" birleştirmezseniz böylece yalnızca değişiklikler insan müdahalesi gerektirir. Müşterileriniz yalnızca özelleştirmeler için değil, bakımı için ödeme yaparsa, bu geçerli bir iş modeli olabilir.

(Ve nay-sayers) sorumu, her müşteriye teslimattan sorumlu özel bir kişi var mı? Diyelim ki, 10.000 kişilik bir şirketseniz, durum böyle olabilir.

Bu , bazı durumlarda eklenti mimarisi tarafından ele alınabilir , diyelim ki çekirdeğinizin gövdesi, eklentiler bagajda veya dallarda tutulabilir ve her müşterinin yapılandırması benzersiz bir şekilde adlandırılmış bir dosyadır veya müşteri şubesinde tutulur.

Eklentiler çalışma zamanında yüklenebilir ya da derleme zamanında yerleşik olabilir.

Gerçekten birçok proje bu şekilde yapılır, temelde aynı sorun hala geçerlidir - basit temel değişiklikler bütünleşmek için önemsizdir, çatışma değişiklikleri geri alınmalı ya da birçok eklentide değişiklik yapılmalıdır.

Eklentilerin yeteri kadar iyi olmadığı durumlar vardır, o zaman çekirdeğin birçok içindekileri ayarlanması gerektiğinde, eklenti arayüz sayısı işlenemeyecek kadar büyük hale gelir.

İdeal olarak, bu , gövdenin çekirdek kod olduğu ve dalların da yön olduğu, boyuta yönelik programlama tarafından ele alınacaktır (ekstra kod ve ekstraları göbeğe nasıl bağlayacağınızla ilgili talimatlardır).

Basit bir örnek olarak, fooözelin çekirdekten önce veya sonra koştuğunu veya klass.foodeğiştirdiğini ya da sardığını ve giriş veya çıkışı değiştirebileceğini belirtebilirsiniz.

Bunun için bir sürü kütüphane var, ancak birleşme çatışmaları sorunu ortadan kalkmıyor - temiz birleşme AOP tarafından yönetiliyor ve çatışmalar hala insan müdahalesine ihtiyaç duyuyor.

Son olarak, bu tür bir işletme gerçekten branş bakımı ile ilgilenmelidir , yani müşteriye özel X özelliği o kadar yaygındır ki, tüm müşteriler ödeme yapmasa da, onu çekirdeğe taşımak daha ucuz olur mu?

Belirtiye bakarak hastalığın kök nedenini çözemezsiniz. Bir 'kod yönetimi' yaklaşımı kullanmak semptomatiktir, ancak uzun vadede sizin için işleri çözmez. Kök sebep 'iyi yönetilen' ürün yeteneklerinin, özelliklerinin, bunların uzantılarının ve çeşitlemelerinin eksikliğidir.

Sizin 'özel' kod uzantıları başka bir şey temsil ürün özellikleri ve yetenekleri ve veri alanı diğerlerine değişiklikleri.

Özel özellikleri ne kadar kapsamlı, ne kadar farklı, bağlamsal olarak ne kadar benzer veya ürününüzün kod tabanını 'sterilize etmede' çok fazla rol oynayacak.

Kodladığınız ve sürümünüzden daha fazlası, burası ürün yönetimi, ürün mimarisi ve veri mimarisinin devreye girdiği bir yer. Ciddi anlamda.

Çünkü günün sonunda, kod müşterilerinize iş ve ürün özellikleri / hizmetleri sunmaktan başka bir şey değildir . Şirketiniz bunun için para alıyor.

Bununla daha iyi bir başa çıkabilmek, kod açısından değil, 'yetenekler' açısından gelmelidir.

Siz, şirketiniz ve ürününüz herkes için her şey olamaz. Artık 500 müşteriden oluşan iyi bir gelir tabanına sahip olduğunuza göre, ne yapmak istediğinizi üretmenin zamanı geldi.

Birkaç şey teklif ediyorsanız, ürün kabiliyetlerinizi organize bir şekilde modülerleştirmek mantıklı olacaktır.

Ürünleriniz ne kadar geniş ve derin olacak? Ya da bu, siz aşağı doğru ilerlerken 'hizmet kalitesi' sorunlarına ve 'ürün seyreltme ve parçalanmasına' yol açacaktır.

Bir CRM veya ERP veya sipariş işleme / gönderme veya Microsoft Excel mi olacaksınız ?

Mevcut uzantıları sıvayıp yolu büyük bir yazılım büyük uyum için gereken de çeker ve birleştirir bir başlangıç safhasından edinilen ürünler.

Güçlü bir ürün yönetimi ve veri mimarisi görevlisinin aşağıdakileri haritalandırması gerekir:

• Ana dal, ürün yetenekleri ve özellikler tabanı
• Özel uzantı özellikleri, türleri ve varyasyonları
• Özel alanların önemi ve çeşitliliği

.. tüm bu gevşek ürün iplik / dallarının asimilasyonu ve uyumlaştırılmasının ana uygulamanızın bağlamında uyumlaştırılması için yol haritası oluşturmak.

Not: Benimle iletişime geçin, bunu düzeltmenize yardımcı olabilecek birini biliyorum :)

Bununla ilgili olabilirim. Üzerine birçok proje aldım. Aslında, geliştirme çalışmalarımızın% 90'ı bu gibi şeyleri düzeltiyor. Herkes mükemmel değildir, bu yüzden sürüm kontrolünü doğru şekilde kullanmanızı ve nerede olduğunuzu, mümkünse aşağıdakileri yapmanızı öneririm.

• Şu andan itibaren, bir müşteri bir güncelleme istediğinde, bunları yeni çatal havuza taşıyın.
• Onları birleştirmek istiyorsanız, ilk iş olarak yapın ve çatışmaları çözün.
• Ardından, sorunlarını ve depolarını depolarıyla yönetin ve ustada başlatmak istediğiniz ustaları saklayın. Bu, serbest bırakma çevrimlerine daha fazla zorlanma getirebilir, ancak zamanla tasarruf etmenizi sağlar.
• Yeni müşteriler için ana havuzun ana şubesini koruyun ve ana havuz yalnızca gelecekteki ürünler için üzerinde çalıştığınız şubelere sahip olmalıdır. Eski şubeler daha sonra müşteri havuzlarına geçirildikten sonra silinebilir.

Ben şahsen bir depo ithal var GitHub'dan Bitbucket 40 şubesi bulunan ve 40 depoları oluşturuldu. Sadece dört saat sürdü. Bu WordPress teması varyasyonlarıydı, bu yüzden itin ve çekin hızlıydı.

“İlk seferinde doğru yapmamak” için birçok neden var ve bence onları hızlı bir şekilde kabul eden ve “bu sefer doğru yapmak” için harekete geçenlerin her zaman başarılı olacağını düşünüyorum.