ugrás a tartalomhoz

git és eltérő környezetek

inf · 2013. Már. 12. (K), 03.28
Érdekelne, hogy ti hogyan oldjátok meg gittel azt a problémát, hogy a helyi teszt rendszernél teljesen más config fájlokat kell használni, mint az éles szerveren. Én arra jutottam, hogy be kell tenni az összes config fájlt gitignore-ba, és kézzel feltenni őket éles szerverre. Arra jutottam még, hogyha minden ágon ott van az összes környezethez tartozó config, akkor a gitignore-ba csak az aktuális környezet nevét tartalmazó fájlt kellene betenni, így ha valami változik az éles szerver config-jában, akkor azt is automatizáltan fel lehetne tölteni. Lehet, hogy ennél van jobb megoldás is, csak én nem látom... :o
‹ Automatikus kódkezelés a teszt és az élő weboldal között Tervezési minták ›
 ■
1

+1

szabo.b.gabor · 2013. Már. 12. (K), 07.53
az ilyen környezetfüggő konfig file-okat én sem rakom version control alá. azért ezeket tipikusan évente egyszer kell megírni.
-jóskának semmi köze hozzá, hogy mi a prod szerver adatbázis elérése
-engem nem érdekel ha jóska más néven akarja belőni az adatbázis szervert
-miért kellene minden futáskor ellenőriznie a script-nek, hogy milyen környezetben dolgozik éppen.

én legalábbis így gondolom
2

ha nem ilyen jellegű, vagy

szabo.b.gabor · 2013. Már. 12. (K), 07.55
ha nem ilyen jellegű, vagy mégis szeretnéd gitben, akkor pedig branch
master
develop
localdev

stb
3

branch vs. config?

T.G · 2013. Már. 12. (K), 10.03
Lehet, hogy én értek félre valamit, de nekem ez a branch-config téma nem világos. Mindenki letölti a master-t, majd csinál egy új ágat a saját configjainak?
És mi van akkor, ha fejlesztés közben készülnek új branch-ek, amiket többeknek le kellene szedniük? Akkor abból is csinálnak egy új ágat?

Én azt a roppant egyszerű megoldást használom, hogy ha kényes a jelszó, akkor kihagyom, ha nem, akkor ott van mindenkinek a configja és azt a server name alapján választja ki a program.
5

Ez tetszik, nem gondoltam rá,

inf · 2013. Már. 12. (K), 15.32
Ez tetszik, nem gondoltam rá, hogy server name-el lehet automatizálni. Pont valami ilyesmit kerestem, hogy ne kelljen gitignore-al szenvedni, hanem tényleg teljesen automatikus legyen...
6

Ezt nem igazán értem.

inf · 2013. Már. 12. (K), 15.35
Ezt nem igazán értem. Konkrétan hogy gondoltad? Ha develop-on fejlesztek, akkor mindig rebaseljem a localdev-et, ha látni szeretném az oldalt? Na ez kizárt...
4

Nem próbáltam még, de a

tgr · 2013. Már. 12. (K), 12.58
Nem próbáltam még, de a twelve-factor app ajánlása tetszik: ha környezeti változóként adod át a beállításokat, akkor lazábban csatolt lesz a rendszered (nem kell egy rögzített, verziókezelt könyvtárhierarchiába belehelyezned egy konfig fájlt), és a hozzáférést kezelni is egyszerűbb. A változókat beállító scriptnek meg csinálsz egy külön repót, branchekkel a staging, dev stb. kontextusnak.
7

Ez a twelve factor nem

inf · 2013. Már. 12. (K), 15.43
Ez a twelve factor nem tiszta, hogy hogyan tudnám megoldani jelen helyzetben kb nulla a hozzáférésem a rendszerhez, még a php.ini változtatásért is külön fizetni kell(ene)...

Azon viszont érdemes elgondolkodni, hogy kiemelem külön repo-ba a config-ot, és úgy nem interferálnak a benne lévő változások a tényleges fejlesztéssel. Sőt, még külön repo-t se muszáj használni ehhez, elég a környezeti ágat külön feltenni egy másik mappába a szerverre, amire maga az alkalmazás tud hivatkozni. Nyilván ilyenkor a környezeti ág csak a config mappát használná...

Közben megnéztem, hogy php-ből és htaccess-ből is be tudom állítani, szóval valszeg vagy a domain névhez fogom igazítani a config-ot, vagy az env-ben beállított egy változóhoz. Nem szeretnék mindent az env-ben beállítani, mert a mostani rendszer még elég zavaros, aztán ez a megoldás jár a legkevesebb változtatással... Később majd még refaktorálom az egészet, aztán akkor meglátom, hogy mi legyen... Egyelőre ez is menni fog automatikusan, mert itthon web.config van, a szerveren meg .htaccess, szóval nem akad majd össze a kettő.
8

Bár a SERVER_NAME is jól

inf · 2013. Már. 12. (K), 19.22
Bár a SERVER_NAME is jól használható, azért én inkább a saját környezeti változó mellett döntöttem, mert az egy kicsivel rugalmasabb. Ez a php-ben a $_SERVER alatt jelenik meg.

Beállítása .htaccess-el:

SetEnv APPLICATION_MODE myvalue
Beállítása web.config-al:

Ehhez URL Rewrite modul szükséges az IIS-hez. Először a view server variables-nél hozzá kell adni az engedélyezett változók köréhez, utána az egyes oldalaknál a rule-oknál lehet beállítani, vagy magában a web.config fájlban 1-1 rule alatt:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Imported Rule 1" stopProcessing="true">
                    <match url="^(.*)$" ignoreCase="false" />
                    <action type="Rewrite" url="/entryPoint.php" appendQueryString="true" />
                    <serverVariables>
                        <set name="APPLICATION_MODE" value="myvalue" />
                    </serverVariables>
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>
Arról nincs infom, hogy be lehet e állítani globálisan egy-egy web.config fájlból. Gondolom igen, de nekem ez így pont elég, nincs időm arra, hogy még pluszban keresgéljek ezzel kapcsolatban.
9

Mi a konfigolást úgy oldjuk

MadBence · 2013. Már. 13. (Sze), 02.37
Mi a konfigolást úgy oldjuk meg, hogy van a verziókezelt konfig, ami kvázi a dev környezet beállításait tartalmazza. Ezen kívül van/lehet mindenkinek az egyéni konfigja, ahol bármilyen beállítást felül lehet írni (nincs verziókezelve). Az éles rendszeren nyilván ez a konfig kikapcsolja a debuggolást, az éles db hozzáférései vannak benne, stb.
Tehát egyrészt nem kell kézzel deployolni, és csak egyedül azt a néhány plusz dolgot kell (nagyritkán!) karbantartani, amit amúgy is kézzel csinálna az ember. Ennél jobb megoldást nem nagyon tudok elképzelni.
10

Persze, ez alapból jó is,

inf · 2013. Már. 13. (Sze), 03.28
Persze, ez alapból jó is, nekem az env-es config mode választás azért kellett, mert nincs kidolgozva rendesen a config része ennek az oldalnak, aztán osztályokban van benne egy csomó cucc, ami külön xml vagy ini fájlban kéne, hogy legyen... Egyelőre szerintem minden ilyen osztályt beleszórok egyetlen fájlba, ami megkapja az aktuális mode nevét, azt betöltöm az env-ben megadott mode alapján, aztán kész. Később talán átírom, hogy normális legyen a config kezelés, de most nincs időm ezzel foglalkozni. Szóval ez egy speciális helyzet...