Bağımlılık geliştirme stratejileri: silik mi yoksa orkestrasyon mu?

Birbirimize bağımlı birçok uygulama ve web hizmetimiz var (bazı halka açık ürünler, bazıları dahili ve özel bir "arka ucun" parçası). Bu bileşenlerin her birinin 4 ortamı vardır (belirli amaçlara hizmet eden sunucu / düğüm kümeleri):

• Üretim Dışı
  • DEV- CI'nin push değişiklikleri oluşturduğu entegre geliştirme ortamı; mühendisler için yerel olarak yeniden üretilemeyen bulunması zor hataların giderilmesinde kullanışlıdır
  • QA - Yalıtılmış KG / Test ortamı
  • DEMO - İş ortakları için istikrarlı UAT ortamı
• Üretim
  • LIVE - Canlı / prodüksiyon ortamımız

Kod tanıtımı: LOCAL(geliştiricinin makinesi) => DEV=> QA=> DEMO=> LIVE.

Diyelim ki , kendisi denilen bir DB tarafından desteklenen myappadlı bir RESTful web hizmeti tarafından desteklenen adlı bir uygulama var .mywsmydb

Şu anda, ben dediğimiz şeyin "var düzenledi : Bu bağımlılıkları arasında" promosyon myapp-devişaret ettiği myws-devkullanımlar mydb-dev. Benzer şekilde, kullandığı myapp-qanokta . Aynı için ve .myws-qamydb-qaDEMOLIVE

Bu sorun diyelim ki, ben bir değişiklik yapmak o zaman olduğunu myapp, bu değişiklik yapmak için beni gerektirir mywsve mydbhem de. Ancak her DEVortam bağımlılıklarının ortamlarına işaret ettiğinden DEV, bu değişiklikleri aynı anda planlamak ve sunmak zorunda olduğum anlamına gelir. Ayrıca, bir yapı dengesiz / kırılırsa, genellikle diğer yukarı akış bileşenlerini indirir; değiştirirken mesela bir geliştirici sonları şey varsa mydb-dev, myws-devve myapp-devkümeler genellikle de kararsız hale gelir.

Bunu çözmek için bir araya gelerek " siled " terfi stratejisi olarak adlandırdığım bir teklif hazırlıyorum : bileşenler arası bağımlılıkların tümü bu kılavuzu izler:

• Memba bağımlılıklar bağlıdır DEMObunların üretim dışı ortamın tümü için, kendi alt bağımlılıklar için çevre ( DEV, QAve DEMO); ve
• Yukarı LIVEakım bağımlılıkları üretim ortamlarına aşağı akım bağımlılıkları için ortama bağlıdır

Bu sözleşmeyi kullanmak , hangi myapp-devnoktanın myws-demokullanılacağını gösterir mydb-demo. Benzer şekilde ve myapp-qaişaret eder .myws-demomydb-demo

Burada bulabileceğim avantaj, yapı stabilizasyonu : DEMObelirli bir bileşen için ortamın kararsız hale gelmesi çok daha az olasıdır , çünkü kod DEMOhem DEVve üzerinde sıkı testler yapmadan bunu yapamaz QA.

Eğer bu yöntem bulmak tek dezavantajı, DEMObelli bir bileşen için kırıldığında, tüm tüm üst bağımlılıkları olmayan üretim ortamlarında anda ayrılır. Ancak bunun DEVve üzerinde yapılan testler nedeniyle bunun çok nadir olması gerektiğine karşı çıkardım QA.

Bu gelmiştir var (çok akıllı ve kendimden daha deneyimli) pek çok geliştirici çözdük bu bir problem olmaya ve bu sorun ve çözümleri zaten kendilerine isim varsa ben sürpriz olmaz (I / babası silo adlandırdığım yanı sıra). Bu yüzden soruyorum: Aptal bir promosyon stratejisinin esası herhangi bir eksilerden daha ağır mı ve burada göz ardı edebileceğim eksiler neler?

Gönderinizi doğru okuyorsam, bu teklif iddia edilen sorunların hiçbirini çözmüyor gibi görünüyor.

myapp için her değişiklik yaptığımda, bu benim myws ve mydb'de de değişiklikler yapmamı gerektirir. Ancak her DEV ortamı bağımlılıklarının DEV ortamlarına işaret ettiğinden, bu değişiklikleri aynı anda planlamak ve sunmak zorunda olduğum anlamına gelir

"Siled promosyon stratejisi" sadece bunu daha da kötüleştirecek gibi görünüyor. Eğer myapp v2, myws v2 ve mydb v2 sadece DEV üzerindeyse ve myapp v2 mydb v2'yi çökmemeye bağlıysa, myapp v2'yi DEV üzerinde çalıştırmaya çalıştığımda mydb v1 DEMO'ya çarpacağım ve çöküyor. Esasen siloları sürekli olarak geçersiz kılmaya ya da mydb v2'yi myapp v2 üzerinde çalışmaya başlamadan önce dağıtmak zorunda kalacaksınız. Daha da önemlisi, DEV'de mydb v2'yi asla test etmeyeceksiniz, bu yüzden eğer kırılırsa, DEMO'yu kırana kadar bile öğrenemezsiniz ve sonra tekrar kare olana dönersiniz.

Bir dereceye kadar, iş akışınız nasıl kurulursa kurulsun tanımladığınız sorun kaçınılmazdır, ancak en aza indirilebilir. İşin püf noktası, mydb ve myws arasındaki arayüzün (ve myws ve myapp arasındaki arayüzün) kesin olarak tanımlanmasını sağlamak ve bu arayüzdeki tüm güncellemelerin geriye dönük olarak tam uyumlu olmasını sağlamaktır . İşimde, uygulamalarımız ve hizmetlerimiz arasındaki arayüzü tanımlayan bir XML şemamız var ve dahili araçlarımızın çoğu bu şemalarda uyumsuz güncellemeler yapmamıza izin vermiyor.

Ayrıca, bir yapı dengesiz / kırılırsa, genellikle diğer yukarı akış bileşenlerini indirir; örneğin bir geliştirici mydb-dev değiştirilirken bir şeyleri bozarsa, myws-dev ve myapp-dev kümeleri de genellikle kararsız hale gelir.

Bu bana ciddi bir sorun gibi geliyor ama bir dağıtım sorunu değil. Bozuk bir veritabanı, hizmet ve uygulamanın düzgün çalışmasını kesinlikle engelleyecektir, ancak "kararsız" hale gelmemelidir. Bir tür hata mesajı döndürüyor olmalılar, böylece dev üzerinde myapp çalıştıran herkes sadece çökmek yerine "Üzgünüz, veritabanımız bugün sorun yaşıyor" görüyor.

Sorun, bozuk bir veritabanı bu sorunlara hiç neden oluyorsa, yapabileceğiniz şey "mydb DEV şimdi bozuk olduğunu söyleyebilmenizi sağlayan bazı" geçici silolama "sistemi kurmaktır, lütfen tüm myws DEV sorgularını mydb DEMO'ya yönlendirin. an". Ancak bu, mydb DEV normal şekilde tekrar çalışana kadar geçici düzeltmeler yapmanın bir yolu olmalıdır . Her şey varsayılan olarak bu şekilde "sessiz" ise, o zaman yukarıda tarif ettiğim sorunlara geri dönüyorsunuz çünkü hiç kimse mydb DEV'e karşı koşmuyor.

Muhtemelen teklifinizi bir şekilde yanlış anladığımı hissediyorum, ancak umarım bu cevap en azından yanlış anlaşılmakta olan şeyin ve en iyi nasıl yeniden ifade edilebileceğini açıkça ortaya koymaktadır.