Контроль версій та особистий файл конфігурації

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

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

Однак це все ще здається тимчасовим рішенням.

Чи можете ви запропонувати краще рішення?

Що роблять професіонали?

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

Тут я можу придумати два можливі рішення:

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

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

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

Це розумне рішення.

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

Потім, коли кожен користувач змінює свою особисту конфігурацію, ви записуєте ці зміни у свою локальну копію.

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

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

У нас є дещо цікаве рішення, ми в першу чергу розробники PHP, тому ми використовуємо Phing, який дозволяє створювати автоматизовані завдання, написані на PHP, тому замість того, щоб робити звичайне оновлення svn, ми робимо "оновлення phing", яке викликає оновлення svn, а потім замінює наші конфігу належними змінними, наприклад, config:

$db_user = "${test.db_user}";

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

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

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

Введіть номер версії в особистий файл конфігурації (номер версії формату конфігураційного файлу).

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

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

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

Він дбає про те, щоб злиття було зроблено правильно, але мені це здається досить безпечним.

Ми тут робимо блоки налаштувань. Це можна зробити в Zend так:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

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

Це корисне рішення, засноване на публікації: Зберігання паролів у контролі джерела

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

1. Створіть фіктивний файл комірця та .gitignore його.
2. Створіть файл makefile, який може зашифрувати та розшифрувати конфігураційний файл
3. Зберігайте makefile та зашифрований конфігураційний файл у сховищі
4. Makefile запитує пароль і як зв’язатися з автором пароля.
5. Під час створення проекту, якщо makefile не запустився, порадьте користувача з console.error ("Налаштування файлу [conf / settings.json] відсутнє! Ви забули запустити make decrypt_conf?");
6. Описано чек, щоб переконатися, що конфігураційний файл оновлений.

Ми створили інструмент під назвою Config, який обробляє такі проблеми конфігурації. Що ви зробите, це створити (або імпортувати) 1 головний конфігураційний файл. Потім створіть середовище під назвою Local. У локальному середовищі створіть декілька примірників, 1 екземпляр на користувача. Якщо вам потрібно внести зміни, які є загальними для всієї дошки, як-от додати нову запис конфігурації або змінити ім'я модуля, просто внесіть зміни, і вони будуть застосовані по всій платі. Якщо ви хочете змінити екземпляр / користувача, зробіть це значення конфігурації змінною, а потім змініть змінну. Ця зміна буде застосована лише до вашого примірника / користувача. Усі вони знаходяться під контролем версій. Ви розгортаєте конфігураційні файли за допомогою кнопки "push" або "pull". Параметр "pull" схожий на git pull, але для цього конкретного примірника / користувача.

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