Ефективно відстежують зміни конфігурації від розробника до продукту


9

Це питання є прикладом Spring Boot як приклад, але це може бути будь-яка технологія.

Припускаючи наступне:

  • Середовища (dev / QA / prod) належать різним командам. Це означає, що розробник не повинен мати доступ до конфігурації prod.
  • Конфігурація (скажімо, application.properties) є зовнішньою, тобто не є частиною двійкового
  • Той самий бінарний / пакунок (скажімо, service.jar) розгорнуто у кожному середовищі та контролюється автоматизованим розгортанням

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

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

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


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

Повнофункціональних команд може бути важко досягти в деяких умовах, коли безпека є головним обмеженням.
Матьє Фортін

Я знаю @MathieuFortin. Ось чому я прокоментував це і заздалегідь "хитрий відповідь", а не відповідь. На жаль, це моє ідеальне рішення, але не таке, яке буде працювати для вас.
RubberDuck

Відповіді:


3

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

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

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

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

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

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

Наприклад, я використовую веб-браузер Firefox, і з кожним новим випуском (який я отримую автоматично) певні речі додаються до локальної конфігурації, яку можна перевірити на сторінці "about: config". Це можна порівняти з конфігурацією у вашому "виробничому" середовищі. Оскільки вся конфігурація зберігається суворо сумісно, ​​мені ніколи не потрібно додавати нові налаштування в конфігурацію вручну лише тому, що з’явився новий випуск браузера. І для випадку, коли я хочу щось змінити там (можливо, новий запис, який не був частиною попередньої версії), я або використовую меню Інструменти / Параметри, або сторінку "about: config", і можу знайти запис плюс деякі вид документації. Тому я рекомендую спробувати впровадити вашу систему порівнянним чином.


0

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

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

Члени команди повинні були оновити конфігураційні файли для інших середовищ у відповідний час. Коли прийшов час оновлення для виробництва, команді збирання довелося оновити файл за допомогою явного запиту від команди розробників, хоча запит зазвичай виглядав як "скопіювати файл app.config з QA1 в PROD". Чутливі речі, такі як паролі, були в окремому конфігураційному файлі, і знову лише команда збирання могла отримати доступ до файлу паролів виробництва. Різниця полягала в тому, що розробники зазвичай цього не робиливимагати змін у файли паролів, оскільки у них не було б виробничих паролів. Єдиний раз, коли вони попросять команду побудувати оновити її, це було додавання нового пароля для нової послуги. І навіть тоді розробники, ймовірно, не знали б пароль виробництва, вони знали б лише ключ, який потрібно додати до файлу (наприклад, "newService2.password").

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.