Блог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другой способ в этом случае — создать частное репозиторий. И автоматически экспортировать вашу общедоступную часть репозитория в другое общедоступное репозиторий git с помощью таких сборов, как https://github.com/open-condo-software/gitexporter .

Тогда у вас будет только один источник истины с историей и работа внутри одного репозитория.

Лучше также использовать какой-нибудь скрипт CI, который выполняется gitexport автоматически.

Такой подход называется giterminism