Какова лучшая практика для обработки определенной для системы информации при управлении версиями?

Я плохо знаком с управлением версиями, таким образом, я приношу извинения, если существует известное решение этого. Для этой проблемы в частности, я использую мерзавца, но мне любопытно на предмет того, как иметь дело с этим для всех систем управления версиями.

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

Я мог также:

  1. Реконфигурируйте сервер разработки для совместного использования того же пути как производство
  2. Отредактируйте эти два случаев каждый раз, когда производство обновляется.

Мне не нравится № 1, потому что я сохранил бы приложение гибким для любых будущих изменений. Мне не нравится № 2, потому что, если бы я начинаю разрабатывать на втором сервере разработки с третьим путем, я должен был бы изменить это для каждой фиксации и обновления.

Что лучший способ состоит в том, чтобы обработать это? Я думал:

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

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

  3. Получение по запросу пути из файла конфигурации за пределами управления версиями. Затем у меня должен был бы быть файл конфигурации в том же месте на всех серверах. Мог бы также просто иметь тот же путь для начала.

Существует ли простой способ иметь дело с этим? Я по размышлению его?

6
задан Jon Seigel 29 March 2010 в 04:49
поделиться

6 ответов

Не сделайте НИКОГДА данных конфигурации твердого кода как пути файловой системы и вынудите несколько развертывания соответствовать. Это - темная сторона, где существует много СТРАДАНИЯ.

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

К сожалению, большая часть языка/платформ разработки с готовностью не поддерживают это (в отличие от Ruby on Rails). Поэтому необходимо создать его сами в различных степенях.

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

Я нахожу, что ОЧЕНЬ ценно разработать приложения, чтобы смочь сообщить об их конфигурации и проверить его. В большинстве случаев отсутствие или недопустимый элемент конфигурации должны привести к прерыванию приложения. Как можно больше, выполните ту проверку (и аварийное прекращение работы) при запуске = перестали работать быстро. Значения по умолчанию твердого кода только, когда они могут надежно использоваться.

Абстрагируйте доступ конфигурации так, чтобы большая часть приложения понятия не имела, куда это прибывает из или как это обрабатывается. Я предпочитаю создавать Config классы, которые выставляют конфигурируемые параметры как отдельные свойства (со строгим контролем типов, когда релевантный), затем я "ввожу" их в классы приложений через МОК. Не заставляйте все свои классы приложений непосредственно вызвать необработанную платформу конфигурации Вашей выбранной платформы; абстракция является Вашим другом.

В большинстве промышленного класса (Fortune 500) организации, никто не видит производство (или даже протестируйте), настройки среды кроме администраторской команды для той среды. Конфигурационные файлы никогда не развертываются в выпуске, они отредактированы рукой администраторской командой. В соответствующих конфигурационных файлах, конечно, никогда не зарегистрировались управление исходным кодом бок о бок с кодом. Администраторская команда может использовать управление исходным кодом, но это - их собственный частный репозиторий. Sarbanes-Oxley и подобные инструкции также склонны строго запрещать разработчикам наличие общего доступа к (почти) производственным системам или любым чувствительным данным конфигурации. Будьте внимательны, поскольку Вы разрабатываете свой подход.

Приятного отдыха.

12
ответ дан 8 December 2019 в 12:23
поделиться

Избегайте полных путей по мере возможности.

Не полагайтесь на свое управление текущей версией, чтобы сделать что-то волшебное - можно изменить системы управления версиями в будущем.

Самый простой подход работает на меня: имейте 'config.live', и 'конфигурация' настроена для разработки. Во время развертывания просто перемещают config.live, чтобы сконфигурироваться, и все в порядке. Для более сложных конфигураций может требоваться подкаталог для каждой конфигурации.

Ряд процедур развертывания важен - поскольку конфигурация является только одной областью, которая будет отличаться.

Что-либо более сложное, почти наверняка, вероятно, вызовет больше проблем, чем оно решает.

2
ответ дан 8 December 2019 в 12:23
поделиться

Необходимо всегда разделять historization (что Управление исходным кодом для) от развертывания.

Развертывание включает:

  • определенный набор данных (для которого тег или маркировка, обеспеченная SCM, пригождаются),
  • процесс, управляющий теми данными (для того, чтобы, по крайней мере, скопировать их в правильном месте, но также и расширить некоторые сжатые файлы, и так далее...)

Среди различной операции развертывание делает, необходимо включать de-variabilization фазу.

Переменная является ключевым словом, представляющим что-либо, вероятно, для изменения в зависимости от платформы развертывания (который может быть ПК для непрерывной интеграции, Linux для основной гомологизации, старым Solaris8 для гомологизации подготовки производства и Полным F15K Solaris10 с зонами для производства: это короткий это может варьироваться много). См. ответ Jonathan Leffler для практических примеров.

Переменная может представить путь, версию JVM, некоторые настройки JVM и так далее, и что Вы включаете SCM, должны быть данные с переменными в нем, никогда трудно кодируемые настройки.

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

  • статические (который никогда не будет изменяться),
  • динамические (который должен быть идеально принят во внимание во время сессии во время выполнения),
4
ответ дан 8 December 2019 в 12:23
поделиться

Используйте SCM, такой как Мерзавец для управления версиями и инструмента развертывания, такого как Capistrano для развертывания. Хотя Capistrano был первоначально создан для Ruby on Rails, он прекрасно подходит для использования его для других платформ и языков.

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

1
ответ дан 8 December 2019 в 12:23
поделиться

Мне нравится способ, которым Ruby on Rails имеет дело с этим видом проблемы - определенные для среды конфигурационные файлы. Направляющие поддерживают разработку, тест и производственные соединения с базой данных - управляемый конфигурацией в database.yml файле. Вот сообщение в блоге о создании других определенных для среды параметров конфигурации, это для направляющих, но могло бы дать Вам некоторое представление о том, как сделать что-то подобное для Вашей среды. http://usablewebapps.com/2008/09/yaml-and-custom-config-for-rails-projects/

0
ответ дан 8 December 2019 в 12:23
поделиться

Кажется, что Ваш производственный код является полным на репозитории мерзавца и обновить производство, Вы делаете a git pull? Вы могли бы хотеть попробовать отдельный процесс сборки, который проверяет код из Вашего репозитория и создает чистую сборку (никакая .git папка). Вы могли, мог иметь среду определенные файлы конфигурации, которые содержат Ваши пути, которые копируются или создаются наряду с нею.

0
ответ дан 8 December 2019 в 12:23
поделиться
Другие вопросы по тегам:

Похожие вопросы: