Jak prawidłowo rozmieścić aplikacje PHP?

Question

Jak prawidłowo wdrażać aplikacje od etapu projektowania po produkcję i jak radzić sobie z wieloma konfiguracjami witryn. Wszystkie moje prace są wykonywane przez svn w var/svn/myapp/trunk i faktyczny kod produkcyjny znajduje się w/var/www/myapp.

Sprawdzam najnowszy kod na moim komputerze lokalnym w katalogu o nazwie "myapp_latest_svn". mam miejsce i kod konkretną lokalizację w moim głównym settings.php, który ma H_PATH = „http://myapp.com” & db ustawienia konfiguracyjne dla db_host, db_user_name i hasło_bazy_danych która jak wiecie różne w lokalnych ustawień urządzenia (gdzie localhost/myapp. com to tylko alias Apache) & na serwerze produkcyjnym (witryna działa na żywo 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 deweloperem a produkcją.

Wszystkie prace wykonuję w SVN. Każdego ranka korzystam z aktualizacji SVN, która aktualizuje najnowszy kod do mojego lokalnego repozytorium svn. Kiedy jestem gotowy, aby rozpocząć transmisję, buduję wersję z svn Commit.

Następnie w wydaniu muszę pamiętać, aby zmienić wszystkie odpowiednie pliki dev na ich odpowiedniki produkcyjne. Teraz musiałem ręcznie edytować ustawienia production.php & .htaccess, aby odzwierciedlić zmiany specyficzne dla witryny.

Szukam automatycznego sposobu przejścia z dev do produkcji wraz z wersjonowaniem i bez ręcznej edycji plików, które są podatne na błędy i złe praktyki.

Jednym ze sposobów jest uczynienie wersji produkcyjnej plików 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 edytowanie plików na każdym przejściu z dev do produkcji. Ale to zły sposób robienia rzeczy takich jak ciągła integracja.

Również wykonując wiele 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 on ustawienia settings.php odpowiednimi ustawieniami settings.php, w zależności od lokalizacji, do której wdrażamy. W ten sposób wszystko jest zautomatyzowane. Ale to także kiepska droga.

Ostatni sposób jest

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

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

} else { 

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

} 

To jest w porządku o ile settings.php jest zaniepokojony. Ale co z tym .htaccess, nie możesz sprawdzić jak wyżej w .htaccess.

To czego nie chcę robić za każdym razem, gdy wdrażam moją stronę, że muszę zmienić ustawienia.

Mój schemat DB nie jest w kontroli wersji, więc db nie jest problemem ze mną, tylko settings.php i .htaccess.

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

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

W jaki sposób mogę używać phing, a nawet skryptu powłoki do integracji, nie powodując żadnego z tych problemów podczas budowania z svn na serwerach produkcyjnych.

Może to być przydatne dla wielu twórców aplikacji, którzy chcą być na wolności.

Dzięki z góry,

ocptime

Answer 1

polecam spojrzeć na Capistrano dla swoich nieszczęść wdrażania. Użyłem go do wdrożenia systemów PHP i zrobi wszystko, co opisałeś (z niewielkim działaniem skryptu w twojej implementacji receptury).

Nie przechowuję żadnych plików konfiguracyjnych w moim zdalnym repozytorium - kiedy kupuję w dev, mogę dodać je raz, a następnie zignorować je, więc nie sprawdzam ich przez przypadek. Jeśli chodzi o wdrażanie, mój cap wdrożyć przepis jest tak skonfigurowany, aby zapisać pliki ustawień do wdrożonej wersji. W ten sposób nigdy nie będę musiał martwić się wdrażaniem i brakiem czegoś krytycznego.

Cap zajmuje się także wszystkimi przesłanymi zasobami (dowiązanie symboliczne do katalogów, aby pozostały na miejscu przy każdym wdrażaniu), a także automatycznie tworzy kopie zapasowe wszystkich plików zasobów i bazy danych podczas wdrażania w usłudze Amazon S3. Całkiem fajnie, co?

Answer 2

Przechowuję pliki ustawień i .haccess w SVN pod zmienionymi nazwami plików, np. settings.php.example i .htaccess.example. W ten sposób, gdy tworzę nową wersję, nie muszę się martwić o nadpisywanie.

Answer 3

Mam zadanie Phing o nazwie config, które pyta mnie, w którym środowisku chciałbym skonfigurować kod. Zadaniem akceptuje kilka możliwych wartości: lokalnym, rozwój, produkcję, postoju itp

Gdy mówię to środowisko, odczytuje w odpowiednim pliku .properties (tj local.properties, production.properties itp)

Następny krok będzie kluczowy dla Ciebie: przechowuj szablony plików konfiguracyjnych i htaccess, a następnie uruchom na nich zadanie filterChain replaceTokens, aby ich tokeny zostały zastąpione wartościami z pliku właściwości.

Tworzenie tych plików:

common/build/szablony/settings.tpl

define('H_PATH','##H_PATH##'); 
define('ENVIRONMENT', '##ENVIRONMENT##'); 

build/szablony/htaccess.tpl

http://##H_PATH## 

Build/Właściwości/local.properties

site.H_PATH = localmyapp.com 
site.ENVIRONMENT = local 

build/properties/production.properties

site.H_PATH = myapp.com 
site.ENVIRONMENT = production 

common/build/build.xml

<target name="config"> 
    <input propertyname="env" validargs="local,production">Enter environment name:</input> 
    <property file="build/properties/${environment}.properties" /> 
    <copy file="build/templates/settings.tpl" 
    tofile="config/settings.php" overwrite="true"> 
    <filterchain> 
     <replacetokens begintoken="##" endtoken="##">  
      <token key="H_PATH" value="${site.H_PATH}" /> 
      <token key="ENVIRONMENT" value="${site.ENVIRONMENT}" /> 
     </replacetokens>   
    </filterchain> 
    </copy>  
    <copy file="build/templates/htaccess.tpl" 
    tofile="public/.htaccess" overwrite="true">  
    <filterchain> 
     <replacetokens begintoken="##" endtoken="##">  
      <token key="H_PATH" value="${site.H_PATH}" />               
     </replacetokens>   
    </filterchain> 
    </copy>    
    <echo msg="Configured settings.php and .htaccess for ${environment}" />    
</target>        

Teraz, gdy chcesz skonfigurować witrynę do biegania na miejscu wystarczy wpisać:

phing config 

następnie wpisz:

local 

i naciśnij przycisk powrotu. To jest to! Jedną z ogromnych zalet tego jest to, że nie potrzebujesz już DOWOLNYCH instrukcji if/else w swoim kodzie. Dodatkowo, nie jest zależne od zmiennych $ _SERVER, więc będzie działało poprawnie w linii poleceń.

Answer 4

Możesz myśleć o Capistrano, Magallanes, Deployer, ale one też są scenariuszem. Mogę polecić Ci wypróbować walle-web, narzędzie do wdrażania napisane w PHP z Yii2 po wyjęciu z pudełka. Hostowałem go w naszej firmie od miesięcy, działa sprawnie, wdrażając test, symulując środowisko produkcyjne.

Umożliwia konfigurację zadań przed wdrożeniem, po wdrożeniu, po wydaniu, a następnie można zmienić konfigurację środowiska, na przykład cp db_test.php db.php.

to zależy od grupy narzędzi bash rsync, git, link, ale ogólnie dobrze ui internetowych do pracy, spróbować :)