Ukládání nastavení pro zákazníky (web.config) rubrika: Programování: .Net
8
Martin Sura
Ahoj,
Poslední dobou celkem dost řeším jak ukládat užvatelské nastavení u aplikace pro zákazníky ve web.config a appSettings.config.
Pro představu máme jeden projekt, který má několik nasazení (staging,dev,a pro jednotlivé zákazníky).
Pro každé nasazení se ukládají jiné connection stringy, appsetings atd.
Zatím jsme dospěli k +- třem řešením:
1, Udělat transformace u web.config a app.config a ty mít uložené přímo v projektu (web.customer.config)
U tohoto řešení se mi nelíbí, že při každé změně je potřeba oteřít solution a dané transformační web.config upravit
Každý vývjoář vidí všechny údaje k danému serveru.
2, Transformace dělá build server a každá hodnota je uložena právě na build serveru a při nasazení se jednotlivé hodnoty transformují (naše interní powershell scripty)
U tohoto řešení se mi nelíbí, že při velkém množství hodnot, je editace celkem nepohodlná
3, Transformace dělá build server a jednotlivé nastavení bude uloženo na build serveru (web.customer.config)
Toto řešení jsme ještě nezkoušeli, ale představoval bych si nějaký repozitar (git), kde budou jednotlivé transformace uložené a při nasazení, se z tohoto repozitáře udělá požadovaná transformace.
Pořád ale platí to, že i při jednoduché úpravě bude potřeba nahrát novou verzi transformace do repozitáře. Jinak se mi toto řešení celkem i zamlouvá.
Jak řešíte podobnou situaci vy nebo jak by ste ji řešili?
Díky
9
Petr Voneš
Transformace web.config nepoužívám, právě pro to omezení, kde pro každého zákazníka (transformaci) třeba zavléct do projektu novou build konfiguraci. Zvláště když těch konfigurací je sto i více.
Mám vlastní řešení, MSBuild scripty volané na build serveru, kde se builduje solution jen pro kód a výsledek se použije kromě *.config (ty jsou jen pro vývoj). Konfigurace pro jednotlivé zákazníky jsou pak předpřipravené v úplně jiných adresářích a celým tím build procesem se to spojí a vykopíruje jinam. Tyto konfigurace jsou vlastně šablony, ve kterých jsou proměnné (parametry). V definici build konfigurace pro zákazníka/modul se pak nastaví jméno šablony a hodnoty jednotlivých parametrů, tím není nutné mít fyzické kopie konfigurací pro všechy zákazníky a moduly, ale jen ty co se výrazně liší. Lze to použít jako v CruiseControl tak VSTS.
Tento způsob používam už mnoho let u různých projektů, kde zpravidla počet kombinací konfigurací modul x zákazník jde do tisíců. Při vhodné adresářové struktuře (zákazník/modul + dědičnost hiearchií podadresářů) je to i poměrně snadné na údržbu. Automaticky to i generuje solution jen pro editace těch konfigurací per zákazník, někde jsou součástí konfigurace i další externí XML soubory, takže to tam přidá i schema aby VS napovídalo atd. MSBuildem se dá udělat plno věcí, s několika vlastními tasky.
Stejně tak se mi neosvědčilo, aby vývojáři používali stejné konfigurace jako pak build proces pro deploy. Protože v nich časem udělají chaos, takže je dobré to držet zcela oddělené a nutné změny propagovat.
Komentáře
-
Martin Sura
:
To mi dává smysl a vlastně to připomíná řešení 3 co jsem psal. Akorát teda mně se ty transformace líbí a nechtěl bych o ně přijít. Každopádně dík za odpověď.
—
12.7.2016
-
Petr Voneš
:
Je to 3, ale ne tak jak si to vymyslel Microsoft ve VS. Ty transformace můžeš volat externě s vlastním vstupem a výstupem, je na to přímo MSBuild task. Takže to není závislé na tom, jak je to udělané ve VS a v projektu. Mě ale více vyhovuje vlastní řešení.
—
12.7.2016
-
Martin Sura
:
Jo jo u zákazníka jsem nedávno použil http://ctt.codeplex.com/ a tváří se to v pohodě. Mně na tomhle vlastně jen vadí způsob uložení. Nejlepší by bla nějaká integrace z build serverem, kde by bylo možné tyto transformace přes webové rozhraní vytvářet,testovat a upravovat.
—
13.7.2016
-
Petr Voneš
:
Ta integrace není problém, jak CruiseControl.NET tak VSTS umí předávat parametry do build scriptu.
—
13.7.2016
Pro plný přístup na Devel.cz se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře