сохранение различий в конфигурации между средами разработки и "живыми" средами во время развертывания из SVN
-
06-09-2019 - |
Вопрос
Мы используем ExpressionEngine CMS (php) для создания веб-сайтов.Для каждого сайта мы настраиваем репозиторий subversion и фиксируем установку EE, а также любые пользовательские шаблоны, изображения, javascript и т.д.которые используются.В репозиторий включен файл, содержащий все переменные среды, и файл .htaccess.
У нас есть сервер разработки с рабочей копией репозитория, обновляемой через post-commit, который мы используем для разработки.Когда мы будем готовы к выпуску, мы создадим ветку в subversion, внесем все изменения, необходимые для производственной среды, пометим номер выпуска, экспортируем репозиторий, загрузим его в новый каталог на действующем сервере и установим символические ссылки на файлы.Откат выполняется так же просто, как возврат к символической ссылке на предыдущую версию.
Проблема заключается в том шаге, на котором мы должны изменить переменные среды, которые должны отличаться для серверов разработки и производства.Это такие вещи, как (не) комментирующие правила htaccess, которые перенаправляли бы не в те места, замена ключей API Google map, потому что домены разные, запуск скриптов, которые минимизируют javascript в один запутанный файл, чтобы уменьшить размер и http-соединения, и т.д.
Вопрос в том, как это могло бы быть более автоматизированным?Мы бы с удовольствием сократили процедуру выпуска до минимума.Я знаком с существованием таких инструментов, как Capistrano и Make, но я не уверен, как я мог бы заставить их изменять все необходимые файлы...как бы вы организовали такое мероприятие?Стоит ли тратить время на автоматизацию, когда это происходит, может быть, раз в пару недель?
Решение
Со многими параметрами конфигурации можно было бы справиться, включив $_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>
Другие советы
Я решаю эту проблему, добавляя файл конфигурации в Список игнорирования Subversion.Это уже рассматривалось здесь, в Stackoverflow: смотрите вопрос № 149485
По сути, я сохраняю только setup.default.php
в SVN, и при каждой установке я вручную копирую его в setup.php
который находится в списке игнорирования.Это предотвращает возврат файла в репозиторий.В этот файл редко вносятся изменения, и они могут быть обработаны по мере необходимости.
Другой альтернативой является однократное разветвление файлов конфигурации в ветку выпуска, а затем пометить их как отредактированные в месте назначения, а затем использовать скрипт слияния, который запоминает, как выполнить трехстороннее слияние.Если конфигурация изменится в источнике, то это, скорее всего, приведет к конфликту, что хорошо, потому что вам, вероятно, нужно внести аналогичные изменения в пункт назначения.
Таким образом, вы поддерживаете работоспособность двух деревьев на протяжении всего срока действия проекта:разработка и выпуск.По мере того, как вещи созревают в процессе разработки, вы интегрируете их для выпуска.У вас также может быть третье дерево контроля качества, если у вас более сложный процесс выпуска.
Когда вы извлекаете новый релиз, вы копируете из рабочей области в область "release" (как слияние / интеграция), а не создаете совершенно новую ветку.Если вам также нужен моментальный снимок дерева выпуска на этом этапе, то создайте отдельную ветку / копию / тег, который вы используете только для архивирования.
Кстати:это одна из областей, где волей-неволей блистает - она запоминает то, что вы уже объединили, и никогда не будет пытаться объединить дважды.
Мы решаем эту проблему, поддерживая каталог, специфичный для конфигурации.
Так, например, если у вас разные файлы .htaccess и config.php между разработчиками и производством, они будут храниться в /trunk/config/{environment}/
Мы используем скрипты ant / nant для создания пакетов выпуска, и у скриптов есть задача сборки для каждой среды.Эти задачи собирают файлы, специфичные для конфигурации.
--
Другой комментатор предлагает включить HTTP_POST.К сожалению, я не могу прокомментировать напрямую (недостаточно высокая репутация).Использование HTTP_POST для определения конфигурации среды имеет потенциальные проблемы с безопасностью, поскольку значение этого параметра исходит от клиента.