Jak poprawnie wdrażać aplikacje od projektowania do produkcji i jak radzić sobie z wieloma konfiguracjami lokacji. Cały mój rozwój odbywa się za pośrednictwem svn zlokalizowanego w var / svn / myapp / trunk, a rzeczywisty kod produkcyjny znajduje się w / var / www / myapp.

Sprawdzam najnowszy kod na moim komputerze lokalnym w katalogu o nazwie „myapp_latest_svn”. Mam kod specyficzny dla witryny i lokalizacji w moim głównym pliku settings.php, który ma H_PATH = 'http://myapp.com'i ustawienia konfiguracji db dla db_host, db_user_name i db_password, które, jak wiadomo, są różne w lokalnych ustawieniach komputera (gdzie localhost / myapp.com to tylko alias Apache) i na serwerze produkcyjnym (strona działająca na myapp.com).

Również plik .htaccess różni się od tego na serwerze produkcyjnym. Krótko mówiąc, istnieje wiele różnic między dev a produkcją.

Przechowuję całą moją pracę w SVN. Każdego ranka używam SVN Update, który aktualizuje najnowszy kod do mojego lokalnego repozytorium svn. Kiedy jestem gotowy do uruchomienia, tworzę wersję z svn Commit.

Następnie w wersji muszę pamiętać o zmianie wszystkich odpowiednich plików dev na ich odpowiednik produkcyjny. Teraz musiałem ręcznie edytować ustawienia settings.php i .htaccess, aby odzwierciedlić zmiany specyficzne dla witryny.

Poszukuję automatycznego sposobu przejścia od wersji dev do produkcji wraz z wersjonowaniem i bez ręcznej edycji plików, która jest podatna na błędy i zła praktyka.

Jednym ze sposobów jest, aby produkcyjna wersja plików była tylko do odczytu (0444). W ten sposób, gdy wykonuję eksport svn, nie są one nadpisywane przez wersję dev plików i nie muszę się martwić o edycję plików przy każdym przeniesieniu z dev do produkcji. Ale to zły sposób robienia rzeczy, takich jak ciągła integracja.

Również poprzez tworzenie wielu kopii pliku settings.php (jeden dla localhost, beta i prod). Następnie za pomocą skryptu powłoki, który eksportuje z svn, a następnie po zakończeniu eksportu, zastępuje plik settings.php poprawnym settings.php, w zależności od lokalizacji, w której wdrażamy. W ten sposób wszystko jest zautomatyzowane. Ale jest to także kiepska droga.

Ostatni sposób to

if( eregi ("myapp.com$", $_SERVER['HTTP_HOST']) ){

    define('H_PATH', 'myapp.com');

} else {

    define('H_PATH', 'localmyapp.com');

}

Jest to w porządku, jeśli chodzi o settings.php. Ale co z .htaccess, nie można sprawdzić jak powyżej w .htaccess.

To, czego nie chcę, kończy się za każdym razem, gdy wdrażam moją witrynę, którą muszę zmienić ustawienia.

Mój schemat DB nie znajduje się w kontroli wersji, więc db nie stanowi problemu, tylko ustawienia settings.php i .htaccess.

Również w jaki sposób mogę powiedzieć svn, aby nie aktualizował niektórych katalogów, ponieważ jest to także specyficzne dla witryny (/ log, / cache, / assets, / downloads). Również muszę zachować nienaruszony dostęp do apache (www_data) dla powyższych plików.

Na koniec nie chcę kopiować pustego katalogu trunk i plików .svn na serwer produkcyjny podczas eksportowania.

Jak mogę użyć Phinga lub nawet skryptu powłoki do integracji bez powodowania żadnych z tych problemów podczas budowania z svn na serwery produkcyjne.

Może to być przydatne dla wielu niedoszłych programistów aplikacji na wolności.

Z góry dziękuję,

ocptime