Ukládání nastavení pro zákazníky (web.config) rubrika: Programování: .Net

10 Martin Sura
položil/-a 12.7.2016

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

Komentáře

  • Filip Kinský : Parametrizace při nasazování přes MSDeploy (http://www.asp.net/web-forms/overview/deployment/web-deployment-in-the-e...) ti nevyhovuje? Přijde mi ideální na build serveru vybuildit aplikaci bez jakýchkoliv parametrů závislých na prostředí, z toho udělat MSDeploy balíček a při nasazení tomuhle balíčku předat parametry v souboru SetParameters_EnvXY.xml pro konkrétní prostředí, kam se nasazuje. 15.7.2016
  • Augi : Taky bych se vydal touto cestou. To XMLko pak můžeš mít uložené kde je libo. 19.7.2016
  • Martin Sura : Popravdě s tím MSDeploy a parametrizací nemám zkušenosti. Co jsem koukal, tak se to týká pouze webových aplikací? Nebo jsem něco přehlédl? 19.7.2016
  • Filip Kinský : Máš pravdu, že je to primárně dělané na web aplikace, ale jde tak nasazovat a parametrizovat prakticky cokoliv - my to používáme i na win.services a cmdline apps. Soubor, který chceš parametrizovat, je specifikovaný v parameters.xml ("scope"), takže tam případně změníš web.config na myapp.exe.config. Kus PS scriptu s ukázkou nasazení win.service včetně parametrizace: https://gist.github.com/Buthrakaur/59a216516f5a18d4a32ddf4663c950ab 24.7.2016
odkaz
9 Petr Voneš
odpověděl/-a 12.7.2016
 
upravil/-a 12.7.2016

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:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.