Який найпростіший спосіб мати справу з файлами конфігурації проекту?

Дуже часто в будь-якому проекті є принаймні один конфігураційний файл. Кожного разу, коли я ділюся проектом git, у мене виникає одна і та ж проблема з:

• конфіденційна інформація (кожен розробник має різні паролі БД тощо)
• інформація про конкретне завдання (коли розробник працює над певним завданням, де потрібно змінити деякі налаштування)

Очевидно, що конфігурації потрібно якось ігнорувати, щоб запобігти затопленню даних конкретного розробника до основного сховища. Зараз є кілька способів, якими я звик користуватися, кожен з яких має деякі недоліки:

• .gitignore конфігураційні файли
  • найпростіший спосіб
  • коли розробник клонує репо, файл конфігурації відсутній, і потрібно з'ясувати, де конфігури їх відтворювали
• файл конфігурації не ігнорується. Він містить деяку фіктивну інформацію, і кожен розробник або відстежує та додає її до свого, .git/info/excludeабо встановлює git update-index --assume-unchanged ...у файл
  • файли доступні для всіх, хто клонує репо
  • він містить передові методи, які можуть заплутати людей, які вперше працюють з git
  • коли хтось випадково робить конфігураційні файли, це не дозволить людям тягнути / витягувати (оскільки виключає не працює так само, як .gitignore)
• розповсюджувати конфігураційні файли, суфіксом яких, наприклад, _originalмаючи справжні файли в .gitignore. Потім кожен розробник перейменовує файли на справжні імена
  • файли доступні для всіх, хто клонує репо
  • потрібно шукати всі конфігури у всій програмі та перейменовувати їх

Чи існують інші, можливо, кращі способи вирішити це? Я підозрюю, що чогось мені не вистачає, хоча б якийсь плагін.

Драйвери фільтрів - це "автоматичний" спосіб реалізації варіанту 3, про що детально йдеться в " коли у вашому проекті є секретний ключ, як може бути можливим натискання на GitHub? ":

При smudgeоформленні замовлення скрипт:

• виявити правильні конфігураційні файли для модифікації
• отримати необхідну інформацію (найкраще зберігати поза будь-яким репозиторієм Git ) і замінить значення шаблону на фактичні.

Звідти розробники можуть внести будь-яку модифікацію до цих файлів конфігурації.
Це не матиме значення, тому що cleanскрипт при коміті відновить вміст цього файлу до його початкового значення (шаблону). Випадкового поштовху немає.

Спосіб, як ми це зробили в останньому проекті, над яким я працював, мав мати головний конфігураційний файл, який завантажував локальний конфігураційний файл користувачів, якщо він був присутній, що міг би перезаписати значення за замовчуванням, задані в майстрі, якщо вказано, і оголосив власну конфігураційну інформацію, якщо такої немає в майстер. Локальний файл було додано до gitignore. Таким чином, усі загальні речі можуть бути спільними, а деякі конфігури завжди присутні, і кожен розробник може змінити свій локальний.

Оскільки мені знадобився деякий час, щоб знайти робоче рішення з підказками @VonC, ось повний приклад того, як ігнорувати паролі за допомогою фільтра git clean у заголовному файлі Objective-C.

1. Припустимо, у вас є скрипт конфігурації за замовчуванням, який Config.hмістить це

   // Change "12345" to your password
   #define kPass @"12345"
   #define kConstant 42
   

2. Створіть сценарій, hidepass.shякий відповідає критичним рядкам, і замість цього друкує рядок за замовчуванням

   #!/bin/sh
   awk '{ if (/#define kPass/) print "#define kPass @\"12345\""; else print $0; }'
   exit 0
   

3. Зробіть скрипт виконуваним та додайте його до репо

4. Скажіть git відфільтрувати ваш конфігураційний файл, додавши цей рядок .gitattributes(також додайте .gitattributes до вашого репо)

   Config.h filter=hidepass
   

5. Скажіть git використовувати hidepass.shскрипт для фільтра hidepass під час очищення:

   git config filter.hidepass.clean ./hidepass.sh
   

Ось і все, тепер ви можете змінити пароль у Config.h але git не буде виконувати цю зміну, оскільки вона завжди замінює цей рядок на рядок за замовчуванням при реєстрації.

Це швидке рішення для однорядкового пароля, ви можете зійти з розуму і, наприклад, закінчити рядки, які потрібно ігнорувати, спеціальним рядком і перевірити наявність рядків із цим рядком.

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

Ми почали використовувати шифрування для конфіденційних деталей у конфігурі: Обробка паролів у виробничій конфігурації для автоматизованого розгортання

У випадку git ви можете подивитися, як git attributes filter attributeзробити заміну локальних значень, так і розшифрувати чутливі значення автоматизованим способом.

Ви також можете мати підмодулі, які мають сказати production.ymlі з обмеженим доступом до репо підмодуля.

Одне, що я можу придумати, подібне до методу 2 та методу 1 вище. Де у вас є каталог, де ви зберігаєте складні речі, унікальні для сайту, такі як каталоги конфігураційних файлів, завантажені користувачами файли тощо.

Ви тримаєте лише сам файл конфігурації поза контролем версій, але тоді у вас є фіктивна копія, яка називається дещо інакше, ніж те, що насправді використовує сайт, і цей файл містить докладні інструкції щодо параметрів конфігурації та створення перейменованої копії.

Наприклад, скажімо, у вас є каталог "site_profile". У цьому каталозі ви створюєте файл із назвою "README.settings.php" разом із каталогом "файли", який містить завантажені користувачем файли (як адміністратора, так і користувачів зовнішнього інтерфейсу). Все це знаходиться під контролем версій.

Однак сайт буде запускати свої налаштування з "settings.php", якого тут не буде. Але якби ви перейменували "README.settings.php" у "settings.php", тоді у вас був би необхідний конфігураційний файл (звичайно, після введення ваших налаштувань).

Це дозволить вам повідомити іншим розробникам, що їм потрібно, поза їхнім конфігураційним файлом, зберігаючи власний конфігураційний файл поза сумішшю. Просто встановіть ваш файл конфігурації на ігнорування або ніколи не виконуйте загальний коміт для цього каталогу та нижче.

Це те, що ми робимо на сайтах Drupal, де я працюю, і це працює дуже добре.

У двох згаданих Вами випадках:

• конфіденційна інформація (кожен розробник має різні паролі БД тощо)

  Напишіть свої сценарії так, щоб ці конфіденційні файли зберігалися в домашньому каталозі розробника, а не в каталозі проекту.

• інформація про конкретне завдання (коли розробник працює над певним завданням, де потрібно змінити деякі налаштування)

  Зазвичай я переглядаю налаштування за замовчуванням у сховищі, і тоді, коли ви готуєте свої коміти, ви можете легко перевірити, чи не змінювали ви будь-який із цих параметрів, і повернути їх перед тим, як зробити коміт.

Я змінив свої локальні зміни конфігурації на сховку git. Я використовую git stash apply, а не pop, так що я ніколи не видаляю його з черги схованки. Таким чином я можу використовувати reset --hard, коли захочу.

Не маючи досвіду роботи з Git, але вирішуючи ті самі проблеми в інших контекстах (ідентифікаційні дані для входу в сплячий режим у наборі Spring JUnit або сценарії ANT) для будь-чого, що є специфічним для користувача або залежить від локального середовища користувача:

1. Запропонуйте README з переліком цих залежностей і як налаштувати локальний env для запуску сценарію.
2. Замініть ці залежності у вашому conf на виклики властивостей системи або якимось фреймворком для введення зовнішніх значень. Наприклад, у сценарії ANT ви можете замінити рядки на <sysproperty key="jdbc.username" value="${jdbc.username}"/>, де jdbc.usernameє системна змінна (яку ви можете встановити в Eclipse).

Розробники можуть перевіряти все, що хочуть, тому що конф є агностичним для користувачів.

Перераховано багато хороших варіантів. Ще кілька варіантів, про які слід згадати:

• Додайте всі конфігурації до .gitignore. Потім створіть окремий git-проект із лише файлами конфігурації. (Зберігайте цей GIT # 2 у зовсім іншій папці.) У цьому GIT # 2 створіть кілька сценаріїв, подібних до apply-config /path/to/my_git1,save-config /path/to/my_git1 які копіюють або зберігають файли конфігурації для основного репозиторію GIT.
  • Я вважаю за краще це використовувати підмодулі. Я знайшов роботу з підмодулями громіздкою у великій команді.
  • Потім ви можете відстежувати конфігурації або використовувати кілька репозиторіїв GIT для таких речей, як виробничі налаштування, налаштування налагодження, більш оптимізовані налаштування тощо.
  • Використовує один інструмент (GIT), який всі розуміють.
• Мені подобається ідея шукати в домашній папці такі важливі речі, як інформація про підключення БД. (Згадано @avh)
• Для devOps ви можете розглянути такі речі, як Ansible / Salt / Chef / Puppet для автоматизації розгортання та налаштувань.

Ще одним дуже поширеним варіантом, який популяризує The Twelve-Factor App , є відсутність змінних конфігурації, закодованих у файли, а завантаження їх із змінних середовища. Таким чином, файли у сховищі не потребують особливої ​​обробки.