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

Question

У меня есть несколько проектов на github, которые я выпускаю таким образом, что он готов к развертыванию кем-либо. У меня есть файлы конфигурации, такие как:

my-project
├── config.yaml
├── dev.yaml

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

my-project
├── config.yaml
├── dev.yaml
├── confidential-stuff.yaml
├── more-confidential-stuff.yaml

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

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

Edit: Я мог бы поместить файлы в .gitignore, но они больше не были бы под контролем версий, следовательно, не видны конвейером развертывания.

Answer 1

Рассмотрим что-то вроде EJson библиотеки Shopify. Это позволяет использовать асимметричное шифрование для хранения рабочей конфигурации в репозитории, что означает, что она версионирована вместе с потребляющим кодом.

Вы можете использовать это, чтобы иметь различные наборы конфигурации (например, dev / test / production), сохраняя учетные данные dev / test в виде простого текста, чтобы ваши разработчики могли запускать приложение, но сохраняя зашифрованные производственные учетные данные, чтобы только производственная среда может их расшифровать.

Answer 2

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

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

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

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

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

(!) Как правило, наличие разных веток для хранения разных наборов контента может привести к проблемам. Люди, приходящие из таких инструментов, как TFVC, иногда практикуют «ветвь для этого проекта и другую ветвь для этого проекта», что приводит к неприятностям. Или люди хотят, чтобы ветвь представляла подмножество всего контента, но когда они объединяют его обратно, они удивляются, потому что куча их файлов удаляется из master. Etc ...

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

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

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

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