поддержание различий в конфигурации между dev и live средами при развертывании из SVN - PullRequest
Новая
       38

поддержание различий в конфигурации между dev и live средами при развертывании из SVN

4 голосов
/ 28 мая 2009

Мы используем ExpressionEngine CMS (php) для создания веб-сайтов. Для каждого сайта мы устанавливаем репозиторий subversion и фиксируем установку EE, а также любые используемые пользовательские шаблоны, изображения, javascript и т. Д. В репозиторий включен файл, содержащий все переменные среды и файл .htaccess.

У нас есть сервер разработки с рабочей копией хранилища, обновленной через post-commit, которую мы используем для разработки. Когда мы будем готовы к выпуску, мы создаем ветку в subversion, вносим любые изменения, необходимые для производственной среды, помечаем номер выпуска, экспортируем репозиторий, загружаем его в новый каталог на работающем сервере и символически связываем файлы на месте. Откат так же прост, как создание символической ссылки на предыдущий выпуск.

Проблема в том, что мы должны изменить переменные окружения, которые должны быть разными для разработчиков и производственных серверов. Это такие вещи, как (не) комментирование правил htaccess, которые перенаправляют в неправильные места, замена ключей API карты Google, потому что домены разные, запуск сценариев, которые минимизируют JavaScript в один обфусцированный файл, чтобы сохранить размер и http-соединения, и т.д. .

Вопрос в том, как это может быть более автоматизировано? Мы бы хотели довести процедуру релиза до минимума. Я знаком с существованием таких инструментов, как Capistrano и Make, но я не уверен, как заставить их изменять все необходимые файлы ... как бы вы организовали такую ​​вещь? Стоит ли тратить время на автоматизацию, когда это происходит, может быть, раз в пару недель?

Ответы [ 4 ]

3 голосов
/ 29 мая 2009

Многие параметры конфигурации можно использовать, включив $ _SERVER ['HTTP_HOST'].

Например 

switch ($_SERVER['HTTP_HOST']) {
    case 'developement.domain.com':
        $api_key = "dev environment api key";
        break;
    default:
        $api_key = "live environment api key";
}

Тогда для проблем .htaccess вы можете установить альтернативный файл .htaccess в своем определении vhost, используя директиву AccessFileName: 

<VirtualHost *:80>
    ServerName sitename
    AccessFileName .htaccess-dev
</VirtualHost>
0 голосов
/ 29 мая 2009

Мы имеем дело с этим, поддерживая каталог, специфичный для конфигурации.

Так, например, если у вас есть разные файлы .htaccess и config.php между dev и production, они будут храниться в / trunk / config / {environment} /

Мы используем сценарии ant / nant для создания пакетов выпуска, и сценарии имеют задачу сборки для каждой среды. Эти задачи выбирают файлы конфигурации.

-

Другой комментатор предлагает включить HTTP_POST. К сожалению, я не могу комментировать напрямую (недостаточно высокая репутация). Использование HTTP_POST для определения конфигурации среды имеет потенциальные проблемы с безопасностью, поскольку значение этого исходит от клиента.

0 голосов
/ 29 мая 2009

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

Таким образом, вы поддерживаете два дерева на протяжении всей жизни проекта: разработка и выпуск. По мере того, как дела развиваются, вы интегрируете их в релиз. Вы также можете иметь третье дерево QA, если у вас более сложный процесс выпуска.

Когда вы вытягиваете новый выпуск, вы копируете из рабочей области в область «выпуска» (в виде слияния / интеграции), а не вытягиваете совершенно новую ветвь. Если вы также хотите получить моментальный снимок дерева релизов в этот момент, создайте отдельную ветку / копию / тег, который вы используете только для архивных целей.

Кстати: это одна из областей, где сияет Perforce - она ​​запоминает то, что вы уже слили, и никогда не будет пытаться объединиться дважды.

0 голосов
/ 28 мая 2009

Я справляюсь с этой проблемой, добавляя файл конфигурации в Subversion ignore list . Об этом уже говорилось в Stackoverflow: см. Вопрос # 149485

По сути, я сохраняю setup.default.php только в SVN, и при каждой установке я вручную копирую его в setup.php, который находится в списке игнорирования. Это предотвращает возврат файла в хранилище. В этот файл редко вносятся изменения, и его можно обрабатывать по мере необходимости.

...