Symfony 1.4 лучшая практика конфигурирования производства и разработки - PullRequest
Новая
       12

Symfony 1.4 лучшая практика конфигурирования производства и разработки

2 голосов
/ 05 октября 2011

Я только начинаю с Symfony.

Я использую Git / github как способ управления моим проектом.Я установил два игнорирования для журнала и кеша, что нормально.

Теперь мне нужно настроить производственную площадку.На данный момент в этом небольшом проекте я занимаюсь разработкой и производством на одном и том же сервере, но с разными расположениями файлов и баз данных.

например, 

www.example.com/mysymfonyproject_dev/  < development area
&
www.example.com/mysymfonyproject/      < Live / Production site

На сервере его /homes/sites/example.com/www/mysymfonyproject_dev & /home/sites/example.com/www/mysymfonyproject

Итак, теперь я клонировал свой проект в новую производственную папку.
Это изКонечно, игнорируются папки журналов и кэша, но теперь мне нужно, например, изменить файл database.yml и, возможно, больше, чтобы заставить работать производственную область.

Какой лучший способ справиться с этим?
Есть ли какой-то другой файл, который я должен добавить к .gitignore, который может указать, какая версия этого сайта, например, разработка или производство.

ИЛИ есть ли какой-то другой способ, которым я могу сделать это без использования git?

Какая лучшая практика?

Как вы можете себе представить, я не хочу иметьобновлять файл database.yml каждый раз, когда я делаю git push на свой рабочий сайт.

ОБНОВЛЕНИЕ:

У меня есть среда разработки.То, что я ищу, - это пошаговое руководство по развертыванию в производство.Я мог бы использовать git для этого, но, например, как мне настроить окружение таким образом, чтобы все настройки были правильными при развертывании.Я вижу, что database.yml может иметь разные настройки для постановки и производства, но где тогда я скажу Symfony, что это за сайт?например, как Symfony узнает, что www.example.com/kickboxing является производственным процессом, а www.example.com/kickboxing_dev готовится?

ОБНОВЛЕНИЕ 2:

В конце концов, для моих конкретных требований этоказалось, работает хорошо. 

1 <?php                                                                                                                          
2 
3 
4 require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');
5 
6 $theurl = explode('/', $_SERVER['PHP_SELF']);
7 $mydir = $theurl[1];
8 
9 
10 if ($mydir == "mysymfonyproject")  //live
11 {
12     $configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);
13     sfContext::createInstance($configuration)->dispatch();
14 }
15 else // dev 
16 {
17     $configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'dev', true);
18     sfContext::createInstance($configuration)->dispatch();
19 }

Я думаю, что использование $ _SERVER ['SERVER_NAME'] было бы лучше на локальных машинах, где вы могли бы сконфигурировать свой файл hosts, например mysymfonyproject.local, просто добавив в индексный файл и git repositoryтогда ffine и все файлы переносимы.

Ответы [ 2 ]

6 голосов
/ 06 октября 2011

Поскольку вы обновили свой вопрос, я могу дать вам соответствующую информацию.

Как вы теперь знаете, у вас в Symfony есть система каскадного конфигурирования, которая позволяет различные параметры, например, для соединения с базой данных (среди прочего) для вашей среды разработки и разработки.

Что касается развертывания, Symfony поставляется с задачей, которая использует rsync для развертывания. В общем случае вам не нужно сильно его настраивать, по умолчанию он не будет развертывать фронт-контроллер dev, поэтому он подходит для большинства основных потребностей. Обратите внимание, что даже если сценарий развертывания должен полностью исключить развертывание фронт-контроллеров dev, e Если вы развернете их, они по умолчанию имеют небольшую проверку безопасности, которая разрешает доступ только с локального хоста. Если вам нужно исключить другие файлы из развертывания, вы можете отредактировать config / rsync_exclude.txt

Подробная информация при развертывании здесь: http://www.symfony -project.org / нежное введение / 1_4 / о / 16-Application-Management-Tools # chapter_16_deploying_applications

Однако следует отметить, что этот сценарий развертывания НЕ обрабатывает развертывание базы данных. Вы должны сделать это вручную. Если вам нужно развернуть изменения базы данных в существующей базе данных, вы также можете сделать это руководство или изучить Doctrine Migrations (при условии, что вы используете Doctrine).

Обновление: у вас может быть один контроллер внешнего интерфейса (index.php) для различных приложений и / или сред. Вы можете проверить имя хоста или другие вещи, но самое чистое решение, которое я нашел и использовал, - это установка переменных среды Apache. В моем конфиге Vhost я сделаю: 

<VirtualHost *:80>
  Servername www.myproject.dev
  ...
  SetEnv SYMFONY_APP frontend
  SetEnv SYMFONY_ENV dev
  SetEnv SYMFONY_DEBUG 1
</VirtualHost>

Обратите внимание, что, конечно, у меня будет отдельный Vhost для каждой комбинации приложения / env. Вы не должны развертывать конфигурации vhost, поэтому обычно вам нужно будет установить это только один раз на каждом хосте. Мой модифицированный index.php выглядит так: 

<?php

require_once dirname(__FILE__) . '/../config/ProjectConfiguration.class.php';

$app = isset($_SERVER['SYMFONY_APP']) ? $_SERVER['SYMFONY_APP'] : 'frontend';
$env = isset($_SERVER['SYMFONY_ENV']) ? $_SERVER['SYMFONY_ENV'] : 'prod';
$debug = isset($_SERVER['SYMFONY_DEBUG']) ? $_SERVER['SYMFONY_DEBUG'] : false;

$configuration = ProjectConfiguration::getApplicationConfiguration($app, $env, $debug);
sfContext::createInstance($configuration)->dispatch();

С помощью этой настройки я могу просто удалить frontend_dev.php и любые другие контроллеры внешнего интерфейса, кроме index.php, из моего репозитория.

0 голосов
/ 05 октября 2011

На рабочем сервере рекомендуется:

  • не иметь никаких инструментов, кроме тех, которые абсолютно необходимы для запуска приложения в prod
  • подготовить развернутый продукт в пред-производственной среде с более открытыми правами доступа, чем в среде prod.

Но в вашем случае, где очень хорошо может отсутствовать среда подготовки к работе и где права доступа не так важны, Git может иметь смысл.

В этом случае я рекомендую работать с файлами конфигурации, сохраняя фактические значения вне хранилища VCS .

content filter

После этого вы можете воспользоваться фильтром контента, чтобы при оформлении заказа создать фактические значения database.yml .
Сценарий smudge (объявленный в файловой части репо .gitattributes) может определить, в какой среде он выполняется, и выбрать соответствующий источник, чтобы получить правильные значения для построения файла.
См. " Git Config excludefile только для ветки " для получения более подробной информации.

...