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

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

database_password=secret
foo=bar

становится

database_password=*
foo=bar

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

Пример:

Локальная версия:

database_password=own_secret
foo=bar

конфигурационный файл в vcs:

database_password=*
foo=bar

Затем неожиданно изменяется файл конфигурации:

database_password=*
foo=bar
baz=foo

И локальная версия станет для каждого разработчика:

database_password=own_secret
foo=bar
baz=foo

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

Ответ 1

Вместо версии, управляющей фактическим файлом конфигурации, вы можете поместить файл шаблона или файла по умолчанию в элемент управления версиями и script, который будет запрашивать информацию и учетные данные БД для создания реального файла конфигурации, который будет исключен из (т.е. игнорируется) контролем версий. При проверке разработчики могут запустить этот script, чтобы получить рабочую среду. Этот script также можно вызвать как часть любого процесса установки, используемого вашим приложением.

Также см. мой ответ на аналогичный вопрос.

Ответ 2

Не знаете, как реализован ваш конфиг, но с иерархическими переопределениями я бы справился с этим.

У вас есть основная конфигурация, которая содержит общую конфигурацию плюс фиктивное имя пользователя/пароль (или вообще оставить их). Затем каждый разработчик создает локальный файл override.config(или что-то еще) со своим конкретным именем пользователя/паролем. Основная конфигурация находится под контролем источника, локальные переопределения разработчика (или машины) этого не делают.

Я делал это в .NET, но не PHP, поэтому я не знаю, насколько это легко, я боюсь.

Ответ 3

Создайте локальный файл переопределений, содержащий пользовательскую информацию в виде переменных PHP.

Например, создайте файл local_overrides.php, который содержит следующее:

$local_password = 'qUzaEAFK13uK2KHy';

Затем в файле, который содержит ваш пароль для БД, сделайте что-то вроде этого

$overrides = 'local_overrides.php';

if (file_exists($overrides)) {
   #include_once($overrides);
   $db_password = $local_password;
} else {
   // perform appropriate action: set default? echo error message? log error?    
   $db_password = 'l1m1t3d!'
}

Локальный файл переопределений никогда не будет отображаться с помощью элемента управления источником.

Ответ 4

Как насчет того, чтобы крюк pre-commit удалял чувствительные поля? Это предполагает, что вам удобно отправлять файл по сети в первую очередь, конечно.

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

Ответ 5

Есть ли отдельный файл с ТОЛЬКО секретами, не находящимися под управлением версиями?

Или, в идеале, покончить с паролями, полностью использовать openssh или аналогичные, и аутентификацию открытого/закрытого ключа для каждого пользователя.

Ответ 6

Я использую для этого файл txt со структурой конфигурационного файла. И после этого я сделаю копию и изменю расширение, и пусть моя система контроля версий проигнорирует этот файл (ы).

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

Ответ 7

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

Я не вижу способа сделать это, а не этого. Если вы найдете другой подход, поделитесь им.

Ответ 8

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

Ответ 9

Мой предпочтительный ответ на это уже упоминался здесь: проверьте фиктивный файл, сгенерируйте "реальный" файл, скопировав файл фиктивного файла во время выполнения и проигнорируйте "настоящий" файл в вашем VCS.

Я уже ответил на аналогичный вопрос, с полным примером, как это сделать в Visual Studio:
как игнорировать файлы в печи/ртути с использованием черепахи hg", которые являются частью хранилища "