Подтвердить что ты не робот

Ветвление: разные конфигурационные файлы для выпуска/разработки

Я унаследовал проект, и мы используем git. У нас есть несколько сред (dev, test, prod). Предыдущая команда в основном воссоздала все на каждом экземпляре, используя те же учетные записи, пароли, sid и т.д. Единственное, что изменилось, это сопоставления имен хостов в /etc/hosts. Чтобы он подключался к другому серверу базы данных.

Теперь это создает проблему, потому что я не могу, например, скопировать схему, чтобы разработчик мог запустить эксперимент с использованием того же экземпляра базы данных, что и основной сервер разработки. Я в основном должен создать новый экземпляр базы данных на другом хосте и изменить /etc/hosts, чтобы указать на этот новый сервер.

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

Другая ситуация, которая может потребовать наличия другой версии файла, может быть отлаживаемой. Предположим, что я использую фреймворк javascript logger, и добавляю код отладки, который я бы не хотел отправлять с выпускной версией. Я не хочу добавлять материал регистратора при разработке/тестировании, а затем удалять его снова, прежде чем отпускать. Можно забыть это сделать.

Каков правильный способ обработки разных "версий" файла для разных ветвей? Есть ли способ иметь ветку, которая остается в синхронизации с последним кодом на главном компьютере, но с несколькими файлами config/code изменены? Я не ожидаю, что он будет оставаться в синхронизации автоматически, но я хотел бы иметь возможность не объединять конфигурационные файлы (или их части), не игнорируя их полностью (?). Например: не объединять строки 6,7 (имя пользователя и пароль db), но объединить другие изменения в файлы.

4b9b3361

Ответ 1

Похоже, вы должны читать атрибуты git. Посмотрите раздел внизу этой страницы

Это полезно, если ветка в вашем проекте расходилась или специализированный, но вы хотите иметь возможность объединить изменения с него, и вы хотите игнорировать определенные файлы. Скажем, у вас есть настройки базы данных файл с именем database.xml, который отличается в двух ветвях, и вы хотите объединиться в другой ветке, не испортив базу данных файл.

Ответ 2

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

Что мы делаем здесь, так это то, что на каждом сервере есть предопределенные переменные среды, указывающие на файл конфигурации, который имеет необходимые учетные данные. Поскольку мы используем Java здесь, это файл типа database.properties, и этот файл никогда не находится внутри системы управления версиями.

Это также позволяет иметь разные настройки и разные учетные данные на каждом сервере