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

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

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

Я мог либо:

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

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

Как лучше всего с этим справиться? Я подумал о:

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

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

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

Есть ли простой способ справиться с этим? Я слишком много думаю об этом?


person Joe    schedule 07.01.2009    source источник


Ответы (6)


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

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

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

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

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

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

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

Наслаждаться.

person Rob Williams    schedule 07.01.2009
comment
Даже если я не согласен с вашим комментарием к моему ответу, я считаю ваш информативным. +1 - person VonC; 08.01.2009

Вы всегда должны отделять историзацию (для чего нужен Source Control) от развертывания.

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

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

Среди различных операций, выполняемых при развертывании, вы должны включить этап девариабилизации.

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

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

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

  • статические (которые никогда не изменятся),
  • динамические (которые в идеале следует учитывать во время сеанса выполнения)
person VonC    schedule 07.01.2009
comment
См. Комментарии к ответу Джонатана Леффлера. Изменение конфигурации во время выполнения опасно (взаимодействие с другим контекстом), но может быть необходимо в РЕДКИХ случаях. - person Rob Williams; 08.01.2009
comment
Позволю себе не согласиться. В вашей производственной среде может быть. Не в нашем. И случаи, когда у вас есть большая ферма серверов, которые нужно настроить, очень редки. Учтите, что, возможно, вы не видели все сценарии производства за свою карьеру. Я знаю, что нет. - person VonC; 08.01.2009
comment
Роб Уильямс: компьютерный консультант с примерно тридцатилетним опытом работы в самых разных технологиях, ролях и отраслях ... хорошо, если подумать, вы, возможно, уже все это видели;) И мой ответ может быть не так хорошо написан . - person VonC; 08.01.2009
comment
@VonC: Я согласен: есть исключения, которые не кажутся исключительными для тех из нас, кто бродил по прериям. Я стараюсь учитывать тот факт, что большинство наших читателей, вероятно, никогда не увидят массивную ферму серверов. Надеюсь, когда они это сделают, они будут знать, как сделать исключение. - person Rob Williams; 08.01.2009

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

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

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

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

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

person Richard Harrison    schedule 07.01.2009


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

person cnk    schedule 07.01.2009

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

person timdisney    schedule 07.01.2009