Různá konfigurace na localu a na produkci – best practice

chikeet

Zdravím,
hledám nějaké čisté a spolehlivé řešení, jak detekovat vývojový a produkční režim a použít podle toho odpovídající konfiguraci. Konkrétně řeším dvě věci:

– detekci development/production – podle čeho, kde, jak nejlíp?
– samotnou konfiguraci – dva .neon soubory? Něco jiného?

Existuje nějaké elegantní řešení, třeba nastavit to nějak v základním config.neon? Stylem „pokud jsi na produkci, includuj tenhle config, a pokud jsi na localu, použij tamten“? To mi přijde ideální, neb config je od slova konfigurace, ale jiným hezkým řešením se taky nebráním.

Chci se vyhnout hlavně tomuhle:

detekování podle IP adresy – přijde mi málo spolehlivé, na něco se zapomene a rozbije se to. Navíc se mi nechce udržovat tohle v X aplikacích a všude to aktualizovat, pokud budu třeba vyvíjet lokálně nějak jinak a změní se pravidla pro detekci. Nemluvě o vývoji ve více lidech, kdy každý používá třeba trochu jiné lokální prostředí.
sahání na Environment
riziko, že si lokální config na produkci přepíšu lokálním configem z vývoje, protože jsou to stejně pojmenované soubory, jen s jiným obsahem

Ráda bych využila co nejlíp to, co v tomhle směru nabízí aktuální verze Nette, jen nevím přesně, jak na to.

Oli

Používám dva soubory

- config.neon
- config.local.neon
- config.production.neon

V bootstrapu potom

$configurator->addConfig(__DIR__ . '/config/config.neon');
if(is_file(__DIR__ . '/config/config.local.neon'))
{
	$configurator->addConfig(__DIR__ . '/config/config.local.neon', $configurator::NONE);

} else
{
	$configurator->addConfig(__DIR__ . '/config/config.production.neon', $configurator::NONE);
}

K tomu používám ftp deployment a config.local.neon je ignorovanej, takže se na produkci nedostane.

ic

jak rozlišit produkci a development…

Já tedy dost sázím právě na ty IP adresy… už na úrovni bootstrap.php si rozhodnu jestli jde o localhost (+ ip adresy localhostu ipv4 a ipv6), tohle je myslím spolehlivé. Podle toho pak rozhoduji jaký použít config.

Pak bývá ještě potřeba sice production (databázové připojení), ale s debugbarem a výpisem chyb, dumpů a noticek. O zapnutí tohoto se pak stará IP adresa kanceláře (nikdo jiný by ji mít neměl). Tento stav se dá pak navodit ještě správnou cookie s tajným obsahem v případě, že je potřeba vypsat si chyby odněkud mimo kancelář či domov. To stejné by se asi dalo zajistit úpravou referreru prohlížeče. A asi i další takové možnosti.

Tak k tomu configu jsou pak jednak zmíněná možnost mít config.neon a config.local.neon a v každém zvláštní konfiguraci, akorát je pak dost pravděpodobné, že se bude sem-tam něco opakovat. Nebo pak mít jen jeden soubor a ten dělený na sekce … viz:

common:
	php:
		date.timezone: Europe/Prague
	.
	.
	.


development < common:

	services:
	.
	.
	.

production < common:

	parameters:
		database:
			host: localhost
	.
	.
	.

console < common:

	.
	.
	.

kalatalabnik

Ahoj, jsem si vědom, že jsi psala:

chikeet napsal(a):

riziko, že si lokální config na produkci přepíšu lokálním configem z vývoje, protože jsou to stejně pojmenované soubory, jen s jiným obsahem

Avšak, je to způsob, který používáme a není s tím problém.

V principu nějak takto: config.neon je součástí repozitáře a obsahuje základní (společnou) konfiguraci. A pak každé prostředí má vlastní config.local.neon (kde jsou nastavení pro dané prostředí, hesla, atp.), který nikdy není součástí repozitáře.

Přepsat tak lokální neon jiným nelze a nemusíme ani řešit detekci prostředí (doménou, IP adresou, či jiným způsobem).

A je to tak i v samotném sandboxu.