Sürüm kontrolü ve kişisel yapılandırma dosyası

Projemiz kullanıcıya özel bir yapılandırma dosyası kullanıyor. Her kullanıcı için farklı olduğundan bu dosya şu anda sürüm denetiminde değildir. Sorun, bir geliştirici yapılandırma gerektiren yeni bir modül eklediğinde veya mevcut bir modülün adını değiştirdiğinde, diğer geliştiriciler hatalarını kendi özel yapılandırma dosyaları güncellenmediği için alır.

Sorunu çözmek için iki yapılandırma dosyasıyla çalışmayı düşündük: sürüm kontrolünde olacak ve yeni bir modül ekleyen her geliştirici tarafından düzenli olarak güncellenecek varsayılan / global bir yapılandırma dosyası ve saklanacak özel bir yapılandırma dosyası sürüm kontrolü ve sadece kullanıcıya özel değişiklikler içerecektir.

Ancak, bu hala geçici bir çözüm gibi görünüyor.

Daha iyi bir çözüm önerebilir misin?

Profesyoneller ne yapar?

Burada zaten bazı iyi cevaplar almanıza rağmen, çoğu sorununuzun temel nedenini özlüyor: kullanıcı yapılandırma dosyalarınız yalnızca kullanıcıya özel bilgilerden daha fazlasını içeriyor gibi görünüyor, ayrıca başka bir yerde sürüm kontrolü altında olan (belki gereksiz) bilgileri de içeriyor , muhtemelen modül isimleri gibi farklı dosyalarda.

Burada iki olası çözümü düşünebilirim:

• bu bilgiyi titizlikle ayırmaya çalışın. Örneğin, kullanıcı ayarlarınızda herhangi bir modül adı kullanmayın. Modüllere başvurmak için kimlik numaralarını (örneğin, GUID'ler) kullanın ve bu kimlik numaralarının bir modüle atandıktan sonra asla değişmemesine izin verin. Elbette, bu muhtemelen kullanıcı yapılandırma dosyalarınızın şu anda sahip olabileceği basitliklerini yitirmesinin dezavantajıdır. Düz bir metin editörü kullanmak yerine, yapılandırma dosyalarınızı düzenlemek için bir GUI aracı oluşturmanız gerekebilir.

• config dosya biçiminize bir sürüm numarası verin ve ne zaman bir modül adı gibi bir şey değiştirildiğinde, onlara yeni bir sürüm numarası atayın. Daha sonra sürüm numaralarını kontrol eden bir yükseltme betiği sunabilirsiniz ve config dosyası güncel değilse, dosyada bulduğu tüm modül adlarını değiştirir ve daha sonra sürüm numarasını artırır. Bu otomatik hale getirilebilir, böylece yükseltme işlemi günlük çalışmalarında takım arkadaşlarınızı rahatsız etmez.

EDIT: Gönderinizi tekrar okuduktan sonra, yeni modüllerin yeni eklendiği ancak yeniden adlandırılmadığı sürece, sözde çözümünüzün makul olduğunu düşünüyorum. Yukarıda yazdıklarım daha sonra modül adlarını veya mevcut modül konfigürasyon yapısını değiştirmeye izin verecek. Fakat buna ihtiyacınız yoksa, en basit çözüme sadık kalacağım.

Bu makul bir çözüm.

Herhangi bir yeni konfigürasyon elemanının (elemanlarının) başlangıç ​​değerlerini belirlemek için bir yol gerekir. Bunlar bir yerde saklanmalı ve global, salt okunur, yapılandırma dosyası açık bir seçimdir.

Sonra her kullanıcı kişisel yapılandırmasını değiştirdiğinde, bu değişiklikleri yerel kopyasına yazarsınız.

Kodunuzun önce genel yapılandırmayı ve değiştirilen değerlerin üzerine yazması için kullanıcıya özel olanı okuması gerekecektir. Bu, yerel olanı okumaktan ve daha sonra hangilerinin ayarlanmadığını ve bu nedenle de genel ayarlar dosyasından okumaya ihtiyaç duymaya çalışmaktan çok daha basit olacaktır.

Depolama için XML gibi bir şey kullanıyorsanız, ayarları kaldırdığınız durumu ele alma konusunda endişelenmenize gerek yoktur. Dosyanın kullanıcı kopyasından talep edilmezler ve dosyayı kaydetme sırasında yeniden yaratırsanız, değişiklikten sonra uygulama ilk kez kullanıldığında kaldırılırlar.

Biraz ilginç bir çözümümüz var, öncelikle PHP geliştiricileriyiz, bu yüzden PHP'de yazılmış otomatik görevler oluşturmanıza izin veren Phing kullanıyoruz, bu nedenle normal svn güncellememizi yapmak yerine, svn güncellemesini çağıran "phing güncellemesi" yapıyoruz, ve sonra config'lerimizi uygun değişkenlerle değiştiririz, örneğin, config:

$db_user = "${test.db_user}";

Bu nedenle, yapılandırma dosyalarının tümü bu ilginç sözdizimiyle sürümlenir ve daha sonra, belirli örneğim için, bu "değişkenleri" değiştirilmemiş ini dosyalarında belirtilen sürümsüz ayarlarla değiştiren, geçici olmayan bir yapılandırma dosyası oluştururuz. Bu şekilde, kullanıcıya özel dosyaları değiştirebilir ve değişikliklerin diğer çalışma kopyaları boyunca doldurulmasını sağlayabiliriz.

Program, yapılandırma dosyasında değer bulunmadığında kodun varsayılan ayarlarında olmalıdır. Bu şekilde yeni şeyler eklendikçe, bozulmayacak, yükseltme yolunuz daha yumuşak olacak ve kullanıcılarınız da yapılandırma dosyasını karıştırdıklarında geri dönüş yapacaklardır.

Başka bir daha karmaşık örnek, program başlangıcında veya başka bir önemli noktada olabilir, bir başlatma modülü kullanarak yapılandırma dosyasını açın ve eksik olan varsayılanları ekleyin, ancak bu oldukça ağır görünüyor.

Kişisel konfigürasyon dosyasına bir versiyon numarası giriniz (konfigürasyon formatının versiyon numarası).

Kişisel konfigürasyon dosyasını işleyen kodun versiyon numarasını kontrol etmesini ve güncel olmaması durumunda güncelleme prosedürünü takip etmesini sağlayın. Bu nedenle, temel olarak, mevcut yapılandırma dosyalarını kıracak bir değişiklik yapan herhangi birinin yapılandırma dosyası biçiminin sürüm numarasını girmesi ve önceki sürümün yapılandırma dosyalarını güncellemek için bir prosedür yazması (bölümleri yeniden adlandırması vb.) Ve yeniden kaydetmesi gerekir. onlar.

Muhtemelen yine de son kullanıcılar için böyle bir işlem isteyeceksiniz, bu yüzden geliştiricilerinizin hayatını kolaylaştırmak için de kullanabilirsiniz.

Genelde bunu nasıl gördüğümü, depoda varsayılan değerleri kontrol eden bir yapılandırma dosyasına sahip olmaktır. Bunlar, örnek olarak, test sunucusunda ihtiyaç duyulan değerler olabilir. Ardından, geliştirici dosyayı teslim aldığında tüm değerlere sahip olur. Yeni bir alan eklenir veya bir alan kaldırılırsa, bu bir birleştirme işlenir. Bir geliştirici, hedef sunucu için gereken değeri kontrol edecek ve kişisel gelişim ortamı için olan alanlardaki diğer değişiklikleri kontrol etmeyecektir.

Birleşmenin doğru yapıldığından emin olmak önemlidir, ancak bu benim için oldukça güvenli görünüyor.

Burada yaptığımız ayar blokları oluşturmak. Bu Zend'de şöyle yapılabilir:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

Bu, testin üretimi miras aldığı ve bunu key3 ile genişlettiği anlamına gelir. Her geliştiricinin yapması gereken her şey ortamını ayarlamaktır (bu durumda test veya üretim).

Bu, gönderiye dayalı yararlı bir çözümdür: Parolaları kaynak kontrolünde tutma

Özetle, strateji "konfigürasyon dosyasının şifrelenmiş bir versiyonunu kaynak kontrolünde tutmak ve daha sonra kullanıcının bu verileri şifreleyip şifresini çözebilmesi için bir araç sağlamaktır".

1. Bir kukla comfig dosyası oluşturun ve .gitignore.
2. Config dosyasını şifreleyebilen ve şifresini çözen bir makefile oluşturun
3. Makefile ve şifreli config dosyasını depoda saklayın
4. Makefile bir şifre ve şifre için yazarla nasıl temasa geçeceğinizi sorar.
5. Proje oluştururken eğer makefile çalışmadıysa, kullanıcıya console.error ("Konfigürasyon dosyası [conf / settings.json] eksik! Çalıştırmayı unuttun make decrypt_confmu?") İle uyarın ;
6. Config dosyasının güncel olduğundan emin olmak için bir kontrol açıklanmıştır.

Bunun gibi yapılandırma sorunlarını ele alan Config adlı bir araç geliştirdik . Yapacağınız şey 1 ana yapılandırma dosyası oluşturmak (veya içe aktarmak). Sonra Yerel adında bir ortam oluşturun. Yerel ortamda, kullanıcı başına 1 örnek olmak üzere birden çok örnek oluşturun. Yeni bir yapılandırma girişi eklemek veya modül adını değiştirmek gibi genel bir değişiklik yapmanız gerekiyorsa, değişikliği yapın ve panoya uygulanır. Bir örnek / kullanıcı değişikliği yapmak istiyorsanız, bu yapılandırma değerini bir değişken haline getirin, ardından değişkeni değiştirin. Bu değişiklik yalnızca kendi örneğinize / kullanıcınıza uygulanacaktır. Bunların hepsi sürüm kontrolü altında. Konfigürasyon dosyalarını push veya pull ile dağıtın. Çekme seçeneği git çekmeye benzer, ancak bu belirli örnek / kullanıcı için.

Config, kullanıcılar arasında yapılandırmaları karşılaştırma, arama, etiketleme, doğrulama ve iş akışı gibi ek özellikler sunar. Bu SaaS, yani henüz bulut için henüz hazır olmayanlar için değil, bir şirket içi planımız var.