Непрерывное развертывание с помощью gitignore

12

При непрерывном развертывании с Git, как вы обрабатываете игнорируемые файлы в gitignore? Эти файлы игнорируются по соображениям конфиденциальности (то есть не хотят, чтобы они передавались в другие удаленные репозитории, например GitHub), но если эти игнорируемые файлы не отправляются в репозиторий непрерывного развертывания, приложение не будет работать (так как игнорируемые файлы требуется для правильной работы программного обеспечения).

Как люди обычно идут об этом? В этом случае Git не лучший кандидат для непрерывного развертывания из-за игнорируемых файлов?

version-control

— user3175663
источник

2

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

— Скудный Роджер

3

Я не вижу недостатка в исследованиях. ОП, кажется, понимает, что Gitignore делает отлично. То, что я вижу, это проблема XY, но поскольку в этом вопросе объясняются и X, и Y, Док смог написать достойный ответ, который, мы надеемся, решит реальную проблему ОП.

— Ixrec

1

@ScantRoger: честно, вопрос можно было бы написать лучше, но это далеко не так плохо, что заслуживает тщательного голосования.

— Док Браун

14

Если ваше программное обеспечение не работает без этих файлов, у вас будут проблемы с любым видом развертывания, ручным, автоматическим или непрерывным, с любым типом VCS или даже без VCS. Так что либо измените ваше программное обеспечение, чтобы оно могло работать фактически без этих файлов (например, оно могло бы принимать какие-то «параметры по умолчанию», если файлы отсутствуют), либо вы предоставляете некоторую версию этих файлов, подходящих для развертывания, которые копируются ( как часть шага развертывания) в среду назначения в случае отсутствия «частной» версии этих файлов.

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

— Док Браун
источник

Согласитесь, если для сборки и запуска недостаточно проверки из vcs, хотя и в уменьшенном объеме, ваше исходное дерево неполно.

— Ньютопия

@Newtopian: обратите внимание, что это может быть действительно преднамеренным и правильным (см. Мой пример).

— Док Браун

2

Другой вариант - хранить конфиденциальную информацию внутри вашего инструмента развертывания. И конфигурация инструмента развертывания в отдельном частном хранилище исходного кода.

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

Например, у Saltstack есть https://docs.saltstack.com/en/latest/topics/pillar/index.html.

— Патрик
источник