Сначала переместите все параметры конфигурации в файл конфигурации (или файлы). Используйте независимый от языка формат, такой как JSON или YAML.
Поместите файл конфигурации / каталог в верхнюю часть дерева исходного кода, где его легко найти.
Задача состоит в том, чтобы поддерживать один репозиторий и иметь разные ветви для разных экземпляров.
Одно репо это хорошо. Разных ветвей нет. Управление многими долгоживущими ветвями быстро становится сложным.
Вместо этого есть одна долгоживущая ветвь, вероятно, master. Используйте функциональные ветки, чтобы изолировать разработку и обеспечить их контроль качества, прежде чем они смогут объединиться в master. Таким образом, master всегда готов к работе. Развернуть прямо с master.
Вот как это может выглядеть. Каждое письмо является коммитом. Каждый [branch] является главой филиала.
I - J L - M - N [feature1]
/ \ /
A - B - C ----- F - G ----- K [master]
\ / \
D - E O - P [feature2]
Здесь показаны две завершенные функции, D - E и I - J, которые уже прошли QA и объединены в master. Поскольку QA уже было выполнено в ветвях компонентов, master развернут в производство. Существуют две открытые ветви функций, каждая из которых периодически запускает git rebase master, поэтому они обновлены до последнего полностью протестированного кода.
Обратите внимание, что нет прямых коммитов на master, они изменяются только через слияние ветвей функций. Это означает, что master всегда тестируется, надежен и готов к развертыванию. Отдельные выполняемые функции не мешают друг другу и могут полагаться на стабильную ветку master; если что-то ломается, они знают, что это из-за их работы, а не потому, что кто-то сломал ветку dev.
А как насчет разных конфигов?
Этот файл, очевидно, будет отличаться для каждой ветви, и этот файл не будет изменен в ветвях.
Наличие одного и того же файла конфигурации в разных ветках - отличный способ получить конфликты, и люди случайно перезаписывают конфигурацию информацией о тестировании и разработке.
Проще иметь один набор файлов конфигурации, который имеет конфигурации для всех различных контекстов, а также параметр по умолчанию для них.
Например, ваша конфигурация базы данных может выглядеть следующим образом в YAML .
default: &default
adapter: postgresql
encoding: unicode
username: postgres
development:
<<: *default
database: myapp_development
host: localhost
test:
<<: *default
database: myapp_test
host: localhost
production: &production
<<: *default
host: our.production.server
username: production_db_user
client1:
<<: *production
database: client1
client2:
<<: *production
database: client2
Здесь используются привязки и псевдонимы YAML для наложения, <<: *default говорит, что включает в себя узел, отмеченный &default. Это устраняет большую избыточность между различными контекстами.
Пусть ваше приложение выберет среду из переменной среды или угадает ее из контекста.
Вот как это делает Rails , несколько файлов конфигурации, каждый с разделами конфигурации для каждого контекста.
Следующий шаг - извлечь секреты производства из исходного кода и поместить их в переменные среды. Секреты - это пароли и ключи API. Затем, когда ваши производственные системы запускаются, они запускаются с установленными переменными среды. Вот как это делают облачные хостинговые сайты, такие как Heroku .
Либо вы можете жестко закодировать секреты производства в ваших конфигурационных файлах, но зашифровать Затем введите ключ дешифрования через переменную среды. Это означает, что вам нужна только одна переменная среды для производства, что может быть проще, если вы переносите старую систему. Вот как TravisCI делает это .
Это может быть куча работы, в зависимости от того, как в данный момент настроена ваша существующая система и рабочий процесс, но это очень удачный шаблон.