22 komentáře “Odlišujete v aplikaci vývojové, testovací a produkční prostředí?

  1. Zpětný odkaz: » Máte jistotu, že do session ukládáte pouze serializovatelné objekty? Myšlenky dne otce Fura

  2. Zpětný odkaz: » Nástroje pro vývoj web aplikací ve Forrestu Myšlenky dne otce Fura

  3. Zpětný odkaz: Myšlenky dne otce Fura » Blog Archive » Fail-fast nebo Fail-tolerant?

  4. Ahoj Honzo, díky za článek,

    my ve firmě používáme nadstavbu nad Springem, s kterou přišel Petr Jůza. Myšlenka je taková, že pro různá prostředí nahrajeme různou sadu XML Spring konfiguráků.

    Kontejner (třeba tomcat) se spustí s -DENV=DEVELOP nebo testy s -DENV=UNITTEST, bez parametru se to bere jako production. Podle toho se řídí naše extense Spring ApplicationContextu a naimportuje /CONF/common/*.xml a /CONF//*.xml. V /CONF/common/*.xml tedy máme ty Spring XML konfiguráky, které jsou společné pro všechna prostředí.

    V CONF/DEVELOP/applicationContext.xml tak třeba nemáme nakonfigurovanou autentizaci přes XML security a nemusíme se tak pořád na webu přihlašovat, stejně tak třeba v PRODUCTION máme jndiDataSource beanu ale v DEVU máme SimpleDataSource.

    Další výhoda je, že pokud se nějaká nastavení sdílejí mezi DEVELOP a UNITTEST, lze je jednoduše naimportovat (v /CONF/UNITTEST/applicationContext.xml může být toto:

  5. Tož my to nemáme takhle explicitně, prostě máme tři balíky s potřebnými konfiguračními soubory a k tomu jakýsi „common“, který je společný všem třem.

    Konfiguraci ve stylu isDevel()/isDebug() z duše nenávídím, blbě se to testuje, způsobuje mrtvý kod a mnohdy se to na produkci chová jinak, než by člověk čekal.

    Nicméně mně je java blízká asi tak jako XML pro konfiguraci, takže nevšímat 🙂

  6. Aha, tak v tomto případě nepomůžu – my to máme prostě napsané na vlastní míru. Kdo ví, jestli někde něco takového existuje, podle charakteru problému bych si ale spíš tipnul že ne, protože je to skoro spíš úkol na nějaký integrační framework než nějakou utility knihovnu.

  7. Ano, je mi to jasné. Jen stojím před podobným problémem, jen nemám vlastní CMS vlastní moduly, ale používám Wicket, Hibernate, logback a pár dalších knihoven a hledám nějaké už hotové řešení, které by pomohlo s konfigurací těchto knihoven dle prostředí.

  8. Jo to parsování XML máme interní – používáme na to JDOM. Pro otestování těch řídících proměnných stačí analýza Java System properties, popřípadě hostname – což je jeden řádek:

    InetAddress.getLocalHost().getHostAddress()

    Nicméně v tom ani není gró toho problému. To přizpůsobení chování aplikace / modulů už s XML nemá v podstatě nic společného. XML je jen prostředek jak to rozlišení prostředí definovat.

  9. A neexistuje nějaká knihovna, která by výběr toho správného konfiguračního souboru řešila? Předpokládám, že to co parsuje ten XML soubor z a podle toho rozhoduje o jaký server jde jste si psali sami?

  10. No spíš se jedná od dva druhy aplikací – my děláme produkt, který má jeden artefakt, který je výsledkem buildu. Tento artefakt se nasazuje na X instalací a tam se teprve customizuje pomocí konfiguračních souborů. Těch konfigurací už tak je poměrně hodně a proto se nám vyplatilo některá „technická“ (nikoliv zákaznická) nastavení typizovat podle zmíněných třech běhových prostředí a vyjmout je ven (s možností přepisu). Moduly, které jsou součástí buildu si mohou potom pro tyto 3 typizovaná prostředí použít své hardcodované defaults.

    Takže řekl bych, že spíš oba řešíme trošku něco jiného.

  11. Zatím jsme evolovali do jiného stavu:
    Běžný překlad probíhá do dev prostředí.
    ant prod a ant test ve vygenerovaném waru přeplácnou specifické konfigurační soubory, šablony, lokalizaci…
    Jiný slovy: konfigurace se mění s účelem buildu, nikoliv za běhu podle prostředí.
    Zdrojové soubory zůstávají stejné. Možná máme jen příliš jednoduché aplikace.

    Ale psát v javě konstrukce typu if (isDevelop()) {…} else {…}? Nevím, to se mi nezdá rozumné.

  12. Ano, pouzivame DEV->TST->PROD model. Konfiguraci udrzujeme v konf. property souborech, pro kazde prostredi zvlast. Zajimavy napad, vybudovat jeste neco nad tim…

  13. Naposledy jsem toto viděl zmíněné v nejnovější verzi iBatis frameworku. Ale obecně bych řekl, že jsem na to dosud v Javovských frameworcích moc nenarazil. Což bych mj. důvod, že jsme tuto strategii adoptovali teprve poměrně nedávno (cca 1/2 roku zpět).

  14. Já konkrétně měl v hlavě taky Railsy, ale tyto dobré metody přejímají dneska skoro všichni. Nevím jak v Javovských frameworcích, ale Grails podle mně ano.

  15. Vsechno genialni je pri zpetnem pohledu jednoduchy princip. Jen nekdo musi udelat vic kroku vyvoje a pak ten zasadni.

    Urcite si myslite (i se ctenari), ze jste to mohli zaridit drive, kdyz mate zkusenosti a vite, jak oddelit jednu funkcnost na jedno misto. Stejne jako po hledani chyby si clovek mysli, ze ji mohl predejit peclivejsi pripravou nebo hlubsim promyslenim. Stejne k nim dochazi. To je holt vyvoj.

  16. Jo, ja bych rekl, ze to takhle pouzivaji skoro vsichni nasi zakaznici – korporatnici. DEV pro hratky a ukazky spot fixu, TST s omezenym pristupem pro nas coby developery pro akceptacni testy a PROD, produkce. Z tech frameworku, ktere to takto deli primo, uvedu napr. Rails. (a timpadem i nejspis Grails 😉