Diyelim ki tipik bir web uygulamanız ve bir dosya yapılandırmanız var. Ne olursa olsun. Proje üzerinde çalışan her geliştiricinin geliştirme kutuları için bir sürümü olacak, bir geliştirme, üretim ve aşama sürümleri olacak. Kaynak kontrolünde bununla nasıl başa çıkıyorsunuz? Bu dosyayı hiç teslim etmiyor musunuz, farklı isimlerle kontrol etmiyor musunuz veya tamamen süslü bir şey mi yapıyorsunuz?
Yanıtlar:
Geçmişte yaptığım şey, kaynak kontrolüne eklenen varsayılan bir yapılandırma dosyasına sahip olmaktı. Daha sonra, her geliştiricinin, kaynak kontrolünün dışında bırakılan kendi geçersiz kılma yapılandırma dosyası vardır. Uygulama önce varsayılanı yükler ve ardından geçersiz kılma dosyası mevcutsa, bunu yükler ve tercihteki geçersiz kılmadan varsayılan dosyaya kadar tüm ayarları kullanır.
Genel olarak, geçersiz kılma dosyası ne kadar küçükse o kadar iyidir, ancak çok standart olmayan bir ortama sahip bir geliştirici için her zaman daha fazla ayar içerebilir.
Yapılandırma olan kod ve bunu sürümü gerekir. Yapılandırma dosyalarımızı kullanıcı adlarına dayandırıyoruz; hem UNIX / Mac hem de Windows'ta kullanıcının oturum açma adına erişebilirsiniz ve bunlar projeye özgü olduğu sürece sorun yok. Bunu ortamda bile geçersiz kılabilirsiniz, ancak her şeyi sürüm kontrolü yapmalısınız .
Bu aynı zamanda başkalarının yapılandırmalarını incelemenizi sağlar ve bu, derleme ve platform sorunlarını teşhis etmeye yardımcı olabilir.
O dosyanın versiyonunu çıkarma. Bir şablon veya başka bir şey versiyonlayın.
Ekibim her ortam için yapılandırma dosyalarının ayrı sürümlerini tutar (web.config.dev, web.config.test, web.config.prod). Dağıtım komut dosyalarımız doğru sürümü kopyalar ve web.config olarak yeniden adlandırır. Bu şekilde, her ortam için yapılandırma dosyaları üzerinde tam sürüm kontrolüne sahibiz, kolayca bir fark gerçekleştirebilir vb.
Şu anda ek bir uzantıya sahip "şablon" yapılandırma dosyam var, örneğin:
web.config.rename
Ancak, kritik değişiklikler değiştiyse bu yöntemle ilgili bir sorun görebilirim.
Şablon yaklaşımında +1.
Ancak bu soruda, kişiselleştirmelerin özel bir test şubesinde tutulduğu, dağıtılmış alternatif kaynak olan Git etiketi olduğu için:
A---B---C---D--- <- mainline (public)
\ \
B'------D'--- <- testing (private)
Bu şemada, ana hat, işlevsel hale gelmek için minimum miktarda ayarlama gerektiren genel bir "şablon" yapılandırma dosyası içerir.
Artık geliştiriciler / test ediciler, yapılandırma dosyasını kalplerinin içeriğine göre ayarlayabilir ve bu değişiklikleri yalnızca bir özel test şubesinde yerel olarak uygulayabilir (örn. B '= B + özelleştirmeleri). Ana hat her ilerlediğinde, onu zahmetsizce teste birleştirirler, bu da D '(= D + B'nin özelleştirmelerinin birleştirilmiş versiyonu) gibi birleştirme işlemleriyle sonuçlanır.
Bu şema, "şablon" yapılandırma dosyası güncellendiğinde gerçekten parlıyor: her iki taraftaki değişiklikler birleştiriliyor ve uyumsuz olmaları durumunda büyük olasılıkla çakışmalara (veya test başarısızlıklarına) yol açıyor!
Kullandığımız çözüm, yalnızca tek bir yapılandırma dosyasına (web.config / app.config) sahip olmaktır, ancak dosyaya tüm ortamlar için ayarları içeren özel bir bölüm ekliyoruz.
Yapılandırma dosyalarımızda her biri o ortamla ilgili yapılandırma anahtarlarını içeren bir LOCAL, DEV, QA, PRODUCTION bölümleri vardır.
Tüm bunları çalıştıran şey, uygulamaya hangi ortamda çalıştığını söyleyen, tüm uygulamalarımızda ( winformlar ve web formları ) referans verilen xxx.Environment adlı bir derlemedir .
Xxx.Environment derlemesi , verilen makinenin machine.config dosyasından, DEV, QA, vb. Üzerinde olduğunu söyleyen tek bir bilgi satırını okur . Bu girdi, tüm iş istasyonlarımızda ve sunucularımızda mevcuttur.
Bu yardımcı olur umarım.
Yapılandırma dosyalarının tüm sürümlerini her zaman kaynak denetiminde, web.config dosyasıyla aynı klasörde tuttum.
Örneğin
web.config
web.qa.config
web.staging.config
web.production.config
Bu adlandırma kuralını tercih ediyorum (web.config.production veya production.web.config'in aksine) çünkü
Varsayılan yapılandırma dosyası, uygulamayı yerel olarak kendi makinenizde çalıştırabileceğiniz şekilde yapılandırılmalıdır.
En önemlisi, bu dosyalar, biçimlendirme dahil her açıdan neredeyse% 100 aynı olmalıdır. Girinti oluşturmak için bir sürümde sekme ve başka bir sürümde boşluk kullanmamalısınız. Aralarında tam olarak neyin farklı olduğunu görmek için dosyalara karşı bir diff aracı çalıştırabilmelisiniz. Dosyaları ayırt etmek için WinMerge kullanmayı tercih ediyorum.
Derleme süreciniz ikili dosyalar oluşturduğunda, bu ortama uygun yapılandırma dosyasıyla web.config'in üzerine yazan bir görev olmalıdır. Dosyalar sıkıştırılmışsa, ilgili olmayan dosyalar bu derlemeden silinmelidir.
Daha önce şablonu, yani web.dev.config, web.prod.config, vb. Kullandım, ancak şimdi 'dosyayı geçersiz kılma' tekniğini tercih ediyorum. Web.config dosyası ayarların çoğunu içerir, ancak harici bir dosya db bağlantıları gibi ortama özgü değerleri içerir. Paul Wilson'ın blogunda güzel bir açıklama .
Bunun, yeni değerler / öznitelikler eklerken acıya neden olabilecek yapılandırma dosyaları arasındaki yineleme miktarını azalttığını düşünüyorum.
Sürüm kontrolü yapıyorum ama asla diğer sunuculara itmiyorum. Üretim sunucusu bir değişiklik gerektiriyorsa, bu değişikliği doğrudan yapılandırma dosyasına yapıyorum.
Güzel olmayabilir ama gayet iyi çalışıyor.
App / web.config'in check-in yapılan, sade vanilya sürümü, tüm geliştirici makinelerde çalışacak kadar genel olmalı ve herhangi bir yeni ayar değişikliği vb. İle güncel tutulmalıdır. Geliştirme için belirli bir ayar setine ihtiyacınız varsa / test / production settings, GateKiller'ın da belirttiği gibi, dosya uzantısını değiştirmemek için genellikle "web.prod.config" ile gidiyorum.
Sürüm kontrolüne eklenen bir şablon yapılandırma dosyası ve ardından şablon dosyasındaki belirli girişleri ortama özgü ayarlarla değiştirmek için otomatik yapımızda bir adım kullanırız. Ortama özgü ayarlar, yine sürüm kontrolü altında olan ayrı bir XML dosyasında saklanır.
Otomatik derlememizde MSBuild kullanıyoruz, bu nedenle değerleri güncellemek için MSBuild Topluluk Görevlerinden XmlUpdate görevini kullanıyoruz .
Uzun zamandır bcwood'un yaptığını tam olarak yaptım. Web.dev.config, web.test.config, web.prod.config vb. Kopyalarını kaynak kontrolü altında tutuyorum ve ardından derleme / dağıtma sistemim bunları çeşitli ortamlara dağıtırken otomatik olarak yeniden adlandırıyor. Dosyalar arasında belirli bir miktarda fazlalık elde edersiniz (özellikle oradaki tüm asp.net öğelerinde), ancak genellikle gerçekten iyi çalışır. Ayrıca, ekipteki herkesin değişiklik yaptıklarında tüm dosyaları güncellemeyi hatırladığından emin olmalısınız .
Bu arada, dosya ilişkilerinin bozulmaması için uzantı olarak ".config" i en sonunda tutmayı seviyorum.
Yapılandırma dosyasının yerel geliştirici sürümlerine gelince, insanları mümkün olduğunca aynı yerel ayarları kullanmaya teşvik etmek için elimden gelenin en iyisini yapmaya çalışıyorum, böylece kendi sürümünüzün olmasına gerek kalmaz. Her zaman herkes için işe yaramaz, bu durumda insanlar genellikle gerektiğinde onu yerel olarak değiştirir ve oradan devam eder. Çok acı verici falan değil.
Projemizde bir önek ile dosyalarda depolanan yapılandırmaya sahibiz, ardından yapı sistemimiz mevcut sistemin ana bilgisayar adına göre uygun yapılandırmayı çeker. Bu, nispeten küçük bir ekipte bizim için iyi çalışır ve yeni bir yapılandırma öğesi eklersek / eklediğimizde diğer kişilerin dosyalarına yapılandırma değişiklikleri uygulamamıza olanak tanır. Açıkçası, bu kesinlikle sınırsız sayıda geliştiriciye sahip açık kaynaklı projelere ölçeklenmiyor.
Burada iki sorunumuz var.
Öncelikle yazılımla birlikte gelen konfigürasyon dosyasını kontrol etmeliyiz.
Bir geliştiricinin, geliştirme ortamında aynı dosyayı kullanıyorlarsa, istemedikleri bir ana yapılandırma dosyasına giriş yapması her ikisi de kolaydır.
Öte yandan, yükleyicinin eklediği ayrı bir yapılandırma dosyanız varsa, ona yeni bir ayar eklemeyi unutmak veya içindeki yorumların geliştirme işlemindeki yorumlarla senkronize olmamasına izin vermek çok kolaydır. yapılandırma dosyası.
Ardından, diğer geliştiriciler yeni yapılandırma ayarları ekledikçe, geliştiricilerin yapılandırma dosyasının kopyasını güncel tutmaları gerektiği sorununa sahibiz. Ancak, veritabanı bağlantı dizeleri gibi bazı ayarlar her geliştirici için farklıdır.
Soru / cevapların kapsamadığı 3. bir problem var. Yazılımınızın yeni bir sürümünü yüklediğinizde, bir müşterinin yapılandırma dosyanızda yaptığı değişiklikleri nasıl birleştirirsiniz?
Henüz her durumda iyi çalışan iyi bir çözüm görmedim, ancak sorunu çok azaltan bazı kısmi çözümler (gerektiğinde farklı kombinasyonlarda birleştirilebilen) gördüm .
Öncelikle, ana konfigürasyon dosyanızdaki konfigürasyon öğelerinin sayısını azaltın.
Müşterilerinizin eşlemelerinizi değiştirmesine izin vermeniz gerekmiyorsa, yapılandırmayı koda taşımak için Fluent NHibernate'i (veya başka şekilde) kullanın.
Aynı şekilde, depency injection kurulumu için.
Yapılandırma dosyasını mümkün olduğunda bölün, örneğin Log4Net'in günlüklerini yapılandırmak için ayrı bir dosya kullanın.
Öğeleri çok sayıda yapılandırma dosyası arasında tekrar etmeyin, örneğin hepsi aynı makineye yüklenmiş 4 web uygulamanız varsa, her uygulamadaki web.config dosyasının işaret ettiği genel bir yapılandırma dosyasına sahip olun.
(Varsayılan olarak göreli bir yol kullanın, bu nedenle web.config dosyasını değiştirmek zorunda kalmak nadirdir)
Gönderi yapılandırma dosyasını almak için geliştirme yapılandırma dosyasını işleyin.
Bu, Xml açıklamalarındaki varsayılan değerlere sahip olarak yapılabilir ve bunlar daha sonra bir derleme tamamlandığında yapılandırma dosyasında ayarlanır. Veya yükleyiciyi oluşturma sürecinin bir parçası olarak silinen bölümlere sahip olmak.
Yalnızca bir veritabanı bağlantı dizesine sahip olmak yerine, her geliştiriciye bir tane sahip olun.
Örneğin, çalışma zamanında yapılandırma dosyasında "database_ianr" (burada ianr benim kullanıcı adım veya makine adımdır) arayın, eğer bulunamazsa, ardından "veritabanı" nı arayın
Geliştiricilerin her iki veritabanı sistemine de erişmesini hızlandıran 2. düzey "örneğin -oracle veya -sqlserver" olması gerekir.
Bu tabii ki başka herhangi bir yapılandırma değeri için de yapılabilir.
Ardından, "_kullanıcıAdı" ile biten tüm değerler, yapılandırma dosyası gönderilmeden önce şeritlenebilir.
Bununla birlikte, sonuçta, konfigürasyon dosyalarını yukarıdaki veya başka bir şekilde yönetme sorumluluğunu üstlenen bir "konfigürasyon dosyasının sahibi" olursunuz. Ayrıca, her sevkiyattan önce müşteri yüzleri konfigürasyon dosyasında bir değişiklik yapmalıdır.
Bu kadar kısa süren bir sorunla ilgilenen birine duyulan ihtiyacı kaldıramazsınız.
Yapılandırma dosyalarındaki verilerin hassasiyetine veya kullandığınız programlama diline ve diğer birçok faktöre bağlı olabileceğinden, tüm durumlarda işe yarayan tek bir çözüm olduğunu sanmıyorum. Ancak tüm ortamlar için yapılandırma dosyalarını kaynak kontrolü altında tutmanın önemli olduğunu düşünüyorum, böylece ne zaman ve kim tarafından değiştirildiğini her zaman bilebilir ve daha da önemlisi, işler ters giderse kurtarabilirsiniz. Ve yapacaklar.
İşte bunu nasıl yapıyorum. Bu genellikle nodejs projeleri içindir, ancak diğer çerçeveler ve diller için de işe yaradığını düşünüyorum.
Yaptığım şey, configsprojenin kökünde bir dizin oluşturmak ve bu dizin altında tüm ortamlar için birden çok dosya (ve bazen her geliştiricinin ortamı için ayrı dosyalar) ve bunların tümü kaynak kontrolünde izleniyor. Ve kodun kullandığı asıl dosya configprojenin kökünde adlandırılmıştır . Bu, izlenmeyen tek dosyadır. Bu yüzden böyle görünüyor
root
|
|- config (not tracked)
|
|- configs/ (all tracked)
|- development
|- staging
|- live
|- James
Birisi projeyi teslim aldığında, izlenmemiş configdosyada kullanmak istediği yapılandırma dosyasını kopyalar ve istediği gibi düzenlemekte özgürdür, ancak gerektiğinde diğer ortam dosyalarına taahhüt vermeden önce bu değişiklikleri kopyalamaktan da sorumludur.
Ve sunucularda izlenmeyen dosya, o ortama karşılık gelen izlenen dosyanın basitçe bir kopyası (veya referansı) olabilir. JS'de bu dosyayı zorunlu kılmak için sadece 1 satırınız olabilir.
Bu akış başlangıçta biraz karmaşık olabilir, ancak büyük avantajları vardır: 1. Bir yapılandırma dosyasının yedeklemeniz olmadan sunucuda silinmesi veya değiştirilmesi konusunda endişelenmenize gerek kalmaz. 2. Bir geliştiricinin kendi özel yapılandırması varsa makinesi ve makinesi herhangi bir nedenle çalışmayı durdurur 3. Herhangi bir dağıtımdan önce , örneğin yapılandırma dosyalarını değiştirebilir developmentve stagingeksik veya bozuk bir şey olup olmadığını görebilirsiniz.
Aynı problemle karşılaştım ve ona bir çözüm buldum. Önce tüm dosyaları merkezi depoya ekledim (ayrıca geliştiriciler de).
Dolayısıyla, bir geliştirici dosyaları depodan alırsa, geliştirici yapılandırması da oradadır. Bu dosyada değişiklik yapılırken Git bu değişikliklerin farkında olmamalıdır. Bu şekilde değişiklikler arşive gönderilemez / kaydedilemez, ancak yerel olarak kalır.
Ben git komutunu kullanarak çözdü: update-index --assume-unchanged. Değişiklikleri Git tarafından göz ardı edilmesi gereken bir dosya içeren projelerin ön yapısında çalıştırılan bir bat dosyası yaptım. İşte yarasa dosyasına koyduğum kod:
IF NOT EXIST %2%\.git GOTO NOGIT
set fileName=%1
set fileName=%fileName:\=/%
for /f "useback tokens=*" %%a in ('%fileName%') do set fileName=%%~a
set "gitUpdate=git update-index --assume-unchanged"
set parameter= "%gitUpdate% %fileName%"
echo %parameter% as parameter for git
"C:\Program Files (x86)\Git\bin\sh.exe" --login -i -c %parameter%
echo Make FIleBehaveLikeUnchangedForGit Done.
GOTO END
:NOGIT
echo no git here.
echo %2%
:END
Ön oluşturmamda yarasa dosyasına bir çağrı yapardım, örneğin:
call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"
SO'da doğru yapılandırma dosyasını web.config / app.config'e kopyalayan bir bat dosyası buldum. Bu yarasa dosyasını ön yapıda da çağırıyorum. Bu yarasa dosyasının kodu:
@echo off
echo Comparing two files: %1 with %2
if not exist %1 goto File1NotFound
if not exist %2 goto File2NotFound
fc %1 %2
if %ERRORLEVEL%==0 GOTO NoCopy
echo Files are not the same. Copying %1 over %2
copy %1 %2 /y & goto END
:NoCopy
echo Files are the same. Did nothing
goto END
:File1NotFound
echo %1 not found.
goto END
:File2NotFound
copy %1 %2 /y
goto END
:END
echo Done.
Ön oluşturmamda yarasa dosyasına bir çağrı yapardım, örneğin:
call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config