Každá aplikace by měla v průběhu svého vývoje procházet několika vývojovými prostředími - vývojové prostředí jednotlivých programátorů, testovací prostředí, prostředí pro akceptační testování a produkční prostředí pro nasazení aplikace u zákazníka. Každé prostředí má svoje specifika - různé konektory k databázím, různé požadavky na spuštěné služby, různé cesty k souborům na lokálních discích, různé konektory ke všem možných dalším systémům jako jsou např. LDAP, email apod.
V minulosti jsme to řešili tak, že v SVN byly uloženy konfigurační soubory pouze pro vývojové prostředí a pro všechny další prostředí jsme to museli dělat nějak ručně. Konf. soubory pro další prostředí jsme tedy drželi bokem a manuálně jsme je před nasazením měnili. Pro nás to na posledním projektu bylo ještě o to horší, že jedna aplikace měla centrální a lokální část.
Jedno z řešení, které se nabízelo, bylo použít filtrací pomocí ANTu. To spočívá v tom, že lokální nastavení pro daného vývojáře se udržuje v souboru (který není součástí SVN) a pomocí ANT tasku se provede filtrace, která mi v konf. souborech provede náhradu značek za mé lokální nastavení. Toto není určitě pro začátek špatné, ale má to několik nevýhod - nedá se moc efektivně udržovat informace pro všechny prostředí, které jsem uvedl a při změně prostředí (např. při přesunu z akceptačního do produkčního prostředí) je nutné generovat vždy novou distribuci, což nemusí být vždy úplně žádoucí.
Během konference SpringOne jsem byl na přednášce, která mi ukázala, že Spring framework mi zase dokáže elegantně pomoci.
Základní myšlenky jsou následující:
- vytvořím si takovou adresářovou strukturu, která bude obsahovat konfigurační soubory pro každé prostředí zvlášť
- vytvořím konf. soubor, kde budu nastavovat jaké prostředí se má spouštět
- upravím inicializaci Springu tak, aby se načetly konf. soubory pouze pro vybrané prostředí
Vzhledem k tomu, že toho psaní je ještě celkem dost, tak jsem se rozhodl, že tento příspěvek rozdělím do dvou částí. Teď končím s úvodem a v příští části popíšu konkrétní implemetaci.
Příspěvky
3 komentáře:
Tipnul bych si, že v příštích dílech půjde o PropertyPlaceholderConfigurer ;).
Máme implementováno podobné řešení. Dovolil bych si jeden tip - nejdřív jsme také museli na konkrétní mašině nastavit nějakou proměnnou, která sloužila k odlišení stroje = konkrétní použité konfigurace.
Skvěle se nám ovšem osvědčilo použít místo této proměnné (která se musela konfigurovat) síťový název stroje, který se dá získat jednoduše jako:
InetAddress.getLocalhost().getHostName()
PropertyPlaceholderConfigurer také používáme, ale myslím, že ty základní myšlenky jsou trochu jiné. Nech se překvapit :).
Rád bych článek napsal co nejdříve, snad mi dneska vyjde čas.
Na Parleys se již objevila prezentace ze SprineOne07, z které jsem vlastně čerpal.
Okomentovat