Vývojová verze webu na produkčním serveru jen pro „vyvolené“
- Bernard Williams
- Člen | 207
Nazdárek,
na produkčním serveru, kde momentálně běží ostrá verze web, bych potřeboval udělat stejnou verzi webu (třeba jako subdoménu), kterou bych využíval jako testovací a kam by měli přístup jen vybraní lidé.
Důvod
- Nemám vlastní server.
- Celou aplikaci vyvíjím na localhostu, ale nemohu si zde otestovat třeba odesílání mailů a celkové chování produkčního serveru.
- Ostrou verzi nemohu dát k otestování, neboť jsou tam ostrá data.
- Testování provádí více lidí (nejen já) a těžko si je mohu vždy zvát domů, aby to otestovali u mě na localhostu :)
- Možnost demonstrace funkcí webu (s postradatelnými daty)
Požadavky
- Neměla by být zaindexovaná ve vyhledávačích
- Do testovací verze se mohou dostat jen určení lidé
- Nutnost provádět co možná nejméně změn při migraci z ostré na vývojovou verzi
Řešení
- Vyhledávačům omezit přístup přes robots.txt (je to 100% způsob?)
- Přihlášení (další instance Environment::getUser(); ) – nebude se prát s tou stávající, které je na webu implementována?
- PostgreSQL: Založit novou databázi nebo využívat schéma public na ostrou verzi a třeba develop na testovací
- Kontrolovat nějaký speciální řetězec URL, který by se pro vstup do vývojové verze musel vepsat ručně (nepraktické/blbost?)
Řešil někdo podobnou situaci?
Jak to řešíte vy?
Nebo vyvíjíte jen na localhostu?
Nějaké nápady nebo postřehy?
Děkuji
Bernard
- Michalek
- Člen | 211
Pro tohle používám autorizaci přes htaccess.
http://radio.feld.cvut.cz/…orizace.html
- arron
- Člen | 464
Urcite bych to udelal na nejakou subdomenu (treba test). Zabezpeceni pres .htaccess zajisti, ze se tam nepujdou roboti a zaroven nebudes muset sahat do prihlasovani aplikace. Mozna by se tam dal zapnout debug mode. Udelat by se to dalo jedna rucne, ale myslim, ze nejaka jednoducha logika do bootstrapu by tomu slusela. No a nakonec bych tomu rozhodne udelal oddelenou databazi (ze zkusenosti, casto clovek udela nekde nejakou blbou chybu a smazat si pod rukama ostrou databazi je fakt neprijemny:-))
- marek.dusek
- Člen | 99
Rozhodne oddelene vsecko, tj. skripty, databaze, verzovani. Doma vyvojujes, commitnes do „test“ vetve, na serveru updatnes, otestuje se, mergnes do „produkcni“ vetve, updatujes produkci.
- newPOPE
- Člen | 648
Bernard Williams napsal(a):
- Celou aplikaci vyvíjím na localhostu, ale nemohu si zde otestovat třeba odesílání mailů a celkové chování produkčního serveru.
Na toto ja pouzivam na WIN7 Argosoft Mail Server instal->vytvorenie konta napr. name@localhost.sk kvoli platnej adrese a mensia uprava php.ini
<?php
[mail function]
; For Win32 only.
SMTP = localhost.sk
smtp_port = 25
?>A uz potom len v TBirde si pozeram ake maily mi prisli ;-)
- Lopo
- Člen | 277
urcite kompletne oddelit – postup ako napisal arron a marek.dusek
jedine co nespomenuli je automatika na config.ini, napr. Environment::loadConfig(‚config-test.ini‘) – a pre uplnu automatiku to obalit do try a odchytavat \FileNotFoundException kde sa zavola loadConfig bez parametrov, tj pokusi sa natiahnut defaultny config.ini
pri takomto rieseni uz staci potom len postupne prekopirovavat subory bez toho aby bolo potrebne este nieco niekde zakazdym prepisovat v suboroch – samozrejme nekopirovat .htaccess z testu do publicu :)