Эффективное отслеживание изменений в конфигурации от разработчика к продукту

Этот вопрос берет в качестве примера сервис Spring Boot, но это может быть любая технология.

Предполагая следующее:

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

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

Например, скажем, команда разработчиков добавляет несколько пар ключ-значение в application.properties в своей среде. Как лучше всего записать эти новые ключи, чтобы при развертывании в ops-команде они точно знали, какие ключи добавить, чтобы минимизировать риск запуска новой службы и ее сбоя из-за отсутствия ключа?

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

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

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

Например, скажем, команда разработчиков добавляет несколько пар ключ-значение в application.properties в своей среде. Как лучше всего записать эти новые ключи, чтобы при развертывании в ops-команде они точно знали, какие ключи добавить, чтобы минимизировать риск запуска новой службы и ее сбоя из-за отсутствия ключа?

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

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

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

Например, я использую веб-браузер Firefox, и с каждым новым выпуском (который я получаю автоматически) некоторые вещи добавляются в локальную конфигурацию, которую можно просмотреть на странице «about: config». Это сопоставимо с конфигурацией в вашей «производственной» среде. Поскольку вся конфигурация поддерживается строго обратной совместимостью, мне никогда не придется добавлять новые ключи в конфигурацию вручную только потому, что есть новая версия браузера. А для случая, когда я хочу что-то там изменить (возможно, новую запись, которая не была частью предыдущей версии), я либо использую меню Инструменты / Параметры, либо страницу «about: config», и могу найти запись плюс некоторые вид документации. Поэтому я рекомендую попробовать внедрить вашу систему аналогичным образом.

В одном месте, где я когда-то работал, у них была похожая проблема. Конфигурация производства контролировалась командой сборки, только они имели доступ к ней в репозитории кода. Конфигурации dev, qa, test и т. Д. Могут видеть все.

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

Члены команды должны были обновить конфигурационные файлы для других сред в соответствующее время. Когда пришло время обновляться для производства, команде по сборке пришлось обновить файл с помощью явного запроса от руководителя группы разработчиков, хотя обычно запрос просто выглядел как «скопировать файл app.config из QA1 в PROD». Чувствительные вещи, такие как пароли, были в отдельном файле конфигурации, и опять же, только команда разработчиков могла получить доступ к файлу производственных паролей. Разница была в том, что разработчики обычно незапрашивать изменения в файлах паролей, потому что у них не было бы производственных паролей. Единственный раз, когда они попросили команду сборки обновить его, это было при добавлении нового пароля для новой службы. И даже тогда разработчики, вероятно, не будут знать пароль производства, они будут знать только ключ, добавляемый в файл (например, «newService2.password»).

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