Geliştirmeden prod'ya yapılan yapılandırmadaki değişiklikleri etkili bir şekilde izleme


9

Bu soru, bir Spring Boot hizmetini örnek olarak alıyor, ancak herhangi bir teknoloji olabilir.

Aşağıdaki varsayımlarla:

  • Ortamlar (dev / QA / prod) farklı ekiplere aittir. Bu, geliştiricinin ürün yapılandırmasına erişimi olmaması gerektiği anlamına gelir.
  • Yapılandırma (diyelim application.properties) harici, yani ikilinin bir parçası değil
  • Aynı ikili dosya / paket (diyelim service.jar) her ortama dağıtılır ve otomatik dağıtım tarafından denetlenir

İkili yapıdaki (service.jar) yapılan değişiklikler otomatik olarak her ortama yayılırken, yapılandırmadaki değişiklikler yine de manuel müdahale gerektirir; bu da kaçınılmaz olarak her ortamda eşitlenmez.

Örneğin, dev ekibinin, application.properties ortamına birkaç anahtar / değer çifti eklediğini varsayalım. Bu yeni anahtarları kaydetmenin en iyi yolu ne olabilir, böylece ops ekibinde dağıtım tam olarak hangi anahtarları ekleyeceklerini bilirler, böylece yeni hizmeti başlatma ve eksik bir anahtar nedeniyle başarısız olduğunu görme riski en aza indirilir?

Manüel adımlar olacağını biliyorum, ancak insanların bununla nasıl başa çıktıklarını bilmek ve en etkili yolu bulmak istiyorum.


Snarky cevap: Siloları yıkın. Devs & ops (ve bir ürün, UX, pazarlama, KG, vb. , tüm ortamlara dağıtımları otomatikleştirin (evet, eşya dahil) ve hayatınıza devam edin.
RubberDuck

Güvenliğin büyük bir kısıt olduğu bazı ortamlarda tam çapraz fonksiyonel ekiplere ulaşmak zor olabilir.
Mathieu Fortin

@MathieuFortin'i biliyorum. Bu yüzden cevaplamak yerine "sinsi cevap" ile yorum yaptım. Bu benim ideal çözümüm, ama ne yazık ki işinize yarayacak bir çözüm değil.
RubberDuck

Yanıtlar:


3

Bu temelde bir iletişim sorunudur, ancak bazı basit teknik ve organizasyonel önlemlerle hataları daha az olası hale getirebilirsiniz. Öncelikle, yapılandırma dosyalarınızdaki tüm girişlerin yanı sıra kolayca erişilebilen bazı örnek veya "varsayılan" yapılandırma dosyası hakkında iyi, yüksek kaliteli bir belge sağlamalısınız. Örnek dosya olabilir doğrudan prod ekibi tarafından değiştirilmesine yönelik değildir çünkü otomatik olarak her ortama dağıtılabilir.

Daha sonra, her yeni sürümde, önemli değişikliklerin belgelendiği bir değişim günlüğü sağlayın. Sistemin eksik olduklarında çalışmasını engelleyebilecek yapılandırma değişiklikleri her zaman önemlidir, bu nedenle bilgilerin orada olduğundan emin olun.

Örneğin, geliştirici ekibinin, application.properties ortamına birkaç anahtar / değer çifti eklediğini varsayalım. Bu yeni anahtarları kaydetmenin en iyi yolu ne olabilir, böylece ops ekibinde dağıtım tam olarak hangi anahtarları ekleyeceklerini bilirler, böylece yeni hizmeti başlatma ve eksik bir anahtar nedeniyle başarısız olduğunu görme riski en aza indirilir?

Başarısızlık riskini azaltmanın en iyi yolu, uygulamanızı yeni anahtarlar gerektirecek şekilde değiştirmekten kaçınmaktır , bu nedenle uygulama mümkün olduğunda eski yapılandırma dosyalarıyla geriye dönük olarak uyumlu olmalıdır. Çoğunlukla, uygulamanız, kayıp oldukları durumda yeni anahtarlar için dahili varsayılan değerler sağlayarak mantıklı bir şekilde davranabilir.

Ancak, bu mümkün değilse, sisteminizin ürün ekibi için anahtar eksik olduğunda yeni hizmetin neden başarısız olduğunu öğrenmesini mümkün olduğunca kolaylaştırması gerekir. Orada anlatan net hata mesajı olmalıdır tam olarak anahtar eksik dosyayı ve gerekiyorsa nerede bilgi bulmak için bu anahtar için anlamlı bir girişle ilgili eksik anahtar veya bir ipucu veya örnek hakkında.

Yapılandırma karmaşıksa ve biçim manuel düzenlemenin hataya eğilimli hale gelmesi biçiminde değişirse, yapılandırmaları düzenlemek ve daha yeni bir sürüme geçirmek için araçlar sağlamayı da düşünebilirsiniz.

Örneğin, Firefox web tarayıcısını kullanıyorum ve her yeni sürümde (otomatik olarak aldığım), "about: config" sayfasında inceleyebileceğiniz yerel yapılandırmaya belirli şeyler ekleniyor. Bu, "üretim" ortamınızdaki yapılandırma ile karşılaştırılabilir. Tüm yapılandırma kesinlikle geriye dönük olarak uyumlu tutulduğundan, tarayıcının yeni bir sürümü olduğundan yapılandırmaya asla yeni anahtarlar eklemem gerekmiyor. Ve orada bir şey değiştirmek istediğim için (belki de önceki sürümün bir parçası olmayan yeni bir giriş), Araçlar / Seçenekler menüsünü veya "about: config" sayfasını kullanıyorum ve girişi artı bazılarını bulabilirim belge türü. Bu yüzden sisteminizi karşılaştırılabilir bir şekilde uygulamaya çalışmanızı tavsiye ederim.


0

Bir zamanlar çalıştığım bir yerde benzer bir problemleri vardı. Üretim konfigürasyonu oluşturma ekibi tarafından kontrol edildi, sadece kod deposunda ona erişebildiler. Dev, qa, test, vs ... konfigürasyonları herkes tarafından görülebilir.

Senin örnekte, bir geliştirici, dosyayı yerel olarak günceller kaynak kontrolüne geçerek kontrol ve sonra birileri yapılandırma dosyaları teslim ve onları konuşlanmış yapı "yalnızca konfigürasyon dosyasında" Yeni yapılacak yapı takımı talep edeceğini, ancak olmadı yeniden derleme veya tüm uygulamayı yeniden konuşlandırın.

Diğer ortamlar için yapılandırma dosyalarını uygun zamanda güncellemek ekip üyelerine kalmıştır. Üretim için güncelleme zamanı geldiğinde, oluşturma ekibi dosyayı geliştirici ekibinden gelen açık bir istekle güncellemek zorunda kaldı, ancak genellikle istek "app.config dosyasını QA1'den PROD'ye kopyala" gibi görünüyordu. Parolalar gibi hassas şeyler ayrı bir yapılandırma dosyasındaydı ve yine yalnızca parola ekibi Üretim parolası dosyasına erişebiliyordu. Fark geliştiriciler genellikle yaptığımız oldu değilÜretim parolaları olmayacaklarından parola dosyalarında değişiklik isteğinde bulunma. Oluşturma ekibinden güncellemelerini istedikleri tek zaman, yeni bir hizmet için yeni bir şifre eklerken oldu. Ve o zaman bile, geliştiriciler muhtemelen Üretim şifresini bilmeyeceklerdi, sadece dosyaya eklenecek anahtarı biliyorlardı ("newService2.password" gibi).

Bunların çoğunu yönetmek için kullanılan teknoloji Jenkins'ti. Jenkins aracılığıyla yapım talep etmek ve programlamak için kullanılan bir şirket içi araç da vardı.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.