viac verzii aplikacie nad jednym kodom – struktura

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
bazo
Člen | 620
+
0
-

ahoj,
momentalne riesim nasledujuci problem:

momentalne mame 3 oddelene verzie tej istej aplikacie, pre kazdu podporovanu krajinu jednu. spravil som jednu verziu ktora zahrna vlastnosti vsetkych doterajsich verzii.
a teraz potrebujeme tie 3 krajiny a dalsie, ktore pridu obsluhovat jednym kodom.

Kazda krajina ma vlastny config.neon kde su specificke nastavenia a potom config.local.neon kde su pripojenia do databazy
kazda krajina ma vlastnu db – z historickych dovodov

pre ostru prevadzku mame domeny konciace na .tld cize .sk, .de, .cz atd
ale na devel serveri mame url sk.domena.eu, cz.domena.eu atd
potom su tu este pocitace vyvojarov kde to moze mat kazdy inak, ja pouzivam system podobny develu

v root folderi projektu sa nachadza skript cli, ktory obsluhuje konzolove prikazy

a teraz sa konecne dostavam k otazke: ako poriesit adresarovu strukturu tak aby prevadzka a setup boli co najjednoduchsie?

podla mna su dve moznosti:

  1. nasmerovat kazdu domenu do rovnakeho www adresara – bud si podla nejakych regexov, ktore moc neviem, zistim o aku krajinu ide, alebo vytvorim pre kazdu krajinu zvlast index v tvare index_sk.php, index_cz.php atd, kde budu zadefinovane cesty ku konfigurakom ktore sa maju nacitat

vyhoda je – staci jeden deploy, logy na jednom mieste,
nevyhody – X verzii suboru index_krajina.php ked budeme pokryvat 20 krajin tak ich tam bude 20, takisto budem musiet mat 20 verzii cli skriptu aby mal spravne konfiguracne udaje

  1. deploynut kazdu verziu ako zvlast aplikaciu

vyhoda – ziadne duplikovanie index.php a cli, jednoduchsie nacitanie konfigu pre krajinu(napriklad podla $ENV)
nevyhoda – X instalacii, X deployov, logy na X miestach, mozem zabudnut pushnut hotfix do 1 z X verzii, zaberie to X krat viac miesta na serveri

ako riesite taketo situacie vy? existuju aj ine riesenia?

vopred dakujem za odpoved

Editoval bazo (21. 10. 2014 10:57)

akadlec
Člen | 1326
+
0
-

imho já bych to řešil detekcí v bootstrapu. Zjistit si jaké je tam tld nebo nějaké jiné pravidlo a podle toho by se načetl specifický neon pro danou jazykovou verzi.

bazo
Člen | 620
+
0
-

ok, dajme tomu ze bude detekcia podla domeny pre web.
ale co s cli?

newPOPE
Člen | 648
+
0
-

Co tak pouzit CLI params. Niekde sme pouzili nieco taketo --mode=development|testing|production kde bootstrap podla toho vyberal mod a konfigurak.

Pripadne Kdyby\Console tam sa tie parametre riesia krajsie.

Editoval newPOPE (21. 10. 2014 13:13)

Tomáš Votruba
Moderator | 1114
+
0
-

@bazo Máme stejnou situaci. Detekci webu řešíme přes hostResolver, který matchne doménu.

Ad CLI, jak píše @newPope, určit web pomocí parametru.
Nejlépe přes vlastní application, která přidá parametr --host ke všem příkazům, jako composer.

akadlec
Člen | 1326
+
0
-

@TomášVotruba mohl by ses trochu rozepsat o tom hostResolveru?

bazo
Člen | 620
+
0
-

tak cli som vyriesil tak ze si poslem param site a potom ho unsetnem z $argv a symfony konzola fici dalej ako po starom.

@TomášVotruba ten hostResolver by zaujimal aj mna

bazo
Člen | 620
+
0
-

ok, tak nakoniec som to vyriesil tak ze som si dal zoznam domen do ini suboru s tym ze existuje aj lokalny zoznam pre kazdeho vyvojara.

pride mi to ako najjednoduchsie a najrychlejsie riesenie

Eda
Backer | 220
+
0
-

Taky mám více webů nad jedním kódem a řešil jsem úplně stejný problém. Nakonec jsem to vyřešil WebResolverem (zřejmě Tomáš má něco podobného, akorát tomu říká jinak).

U mě je to služba, kterou mám registrovanou v DIC a třeba rozdílné databáze pro rozdílné weby řeším tak, že mám vlastní ConnectionFactory, která vyžaduje WebResolver, ze kterého se dozví, na jakém webu jsme a podle toho nastaví připojení. Takto to dělají i jiné služby, které jsou nějak závislé na webu. Jen si prostě vyžádají WebResolver, zavolají getWeb() a je to.

Tomáš Votruba
Moderator | 1114
+
0
-

@akadlec @bazo Zjednodušeně jak to napsal @Eda.

$host = $this->httpRequest->getUrl()->getHost()
$website = $websiteDao->fetchOneBy(['host' => $host]);

Issues, které jsem řešil:

  • Entity manager předávám setterem v DI, jelikož je někdy potřeboval jak hostResolver, tak entity manager, a to způsobuje circular reference.
  • Pro fčnsot v CLI se v DI nastavuje fallback při absenci getHost(), tedy:
$builder->addDefinition($this->prefix('hostResolver'))
	->setClasss('Phc\Application\HostResolver')
	->addSetup('$consoleHost', [$builder->parameters['host']]);

Editoval Tomáš Votruba (24. 10. 2014 9:15)

bazo
Člen | 620
+
0
-

ok, no ja potrebujem nacitat domenu este pred vytvorenim containeru. a pride mi rychlejsie a jednoduchsie nacitat to z ini suboru ako z db. este by som musel mat dalsiu db so zoznamom domen. a v appke uz potom nepotrebujem vediet na ktorej domene som

akadlec
Člen | 1326
+
0
-

@TomášVotruba jasný to vypadá rozumně. Hele řešil si to i pro připojení k DB přes Doctrine?

Tomáš Votruba
Moderator | 1114
+
0
-

@bazo To už je otázka preferencí.

@akadlec Zatím používáme 1 databázi s příznakem website_id. Zkusil bych řešení, co popisuje @eda