Применить изменения для каждой версии

Question

У меня есть приложение, которое общается с веб-сервером. На этом веб-сервере у меня есть два экземпляра. Тестирование одного на моей локальной машине и производственное на удаленной машине. Скажите IP 192.168.0.100 для моей локальной машины и http://mycompany.com/webapi для удаленного.

Я использую поток Git, как описано в (см http://nvie.com/posts/a-successful-git-branching-model/)

Теперь, как только я создать ветку релиза, я хочу перейти от моего локального сервера на удаленный сервер.

IP хранится в публичной конечной статической переменной. Это означает, что повторное применение одного коммита, который изменит его из моего локального IP-адреса на удаленный URL-адрес, будет работать.

Что было бы правильным путем? Я создавал прикрытие и применял его при каждом выпуске, но для кого-то ленивого, как я, который кажется слишком большим ручным трудом, и слишком много шансов на то, что что-то пойдет не так (например, забыв применить накладку)

Answer 1

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

Один общий подход, популяризированный The 12-Factor App и Heroku, чтобы установить IP-адрес, используя переменную окружения:

приложение в конфигурации это все, что может варьироваться между deploys (постановка, производство , среды разработчиков и т. д.). Это включает в себя:

• ресурсов обращается к базе данных, Memcached и другие backing services
• полномочий на внешние услуги, такие как Amazon S3 или Twitter
• Per-разворачивать такие значения, как каноническое имя хоста для Deploy

Приложения иногда сохраняют конфиг в качестве констант в коде. Это является нарушением двенадцатифакторного режима, который требует строгого разделения конфигурации от кода. Конфигурация существенно различается по разным адресам, а код - нет.

...

В двенадцать-фактор приложение хранит CONFIG в переменных окружения (часто сокращается до окр вары или окр). Env vars легко изменить между развертываниями без изменения кода; в отличие от конфигурационных файлов, мало вероятность того, что они будут случайно проверены в репо кода; и в отличие от настраиваемых конфигурационных файлов или других конфигурационных механизмов, таких как Java System Properties, они являются языковым и OS-агностическим стандартом.

Другой распространенный подход (что 12-фактор явно отвергает) является версией пример конфигурационного файла, как config.ini.sample, но требуют от пользователей, чтобы скопировать этот неверсированной и .gitignore д файл как config.ini, фактически используемых приложением. Это позволяет изменять настройки для каждой установки, изменяя файл, который не беспокоит Git.

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