Как Вы рассматриваете развертывание конфигурационных файлов в различных системах в Подверсии?
AmazonSQS также является пружинным бобом, который можно вводить с помощью @Autowired. Таким образом, вы можете изменить конструктор с
@Autowired
public SqssReadderApp(AWSConfig awsConfig) {
this.sqs = awsConfig.generateSQS();
}
на
@Autowired
public SqssReadderApp(AmazonSQS sqs) {
this.sqs = sqs;
}
Теперь вы можете добавить свой макетный экземпляр в конструктор.
Вам также следует рассмотреть возможность устранения этой комбинации инжекции поля и инжектора конструктора. Я рекомендую инъекцию в конструктор, которая значительно облегчает тестирование.
public class SqssReadderApp {
@Autowired
public SqssReadderApp(Source source, AWSProperties awsProperties, AuditRepository auditRepository, AmazonSQS sqs) {
//
}
}
См. Также , почему полевая инъекция является злой .
6 ответов
Я нахожу, что самый легкий путь состоит в том, чтобы включить имя хоста машины. У меня есть .ini файл с общим разделом, который также переопределяет это для производства, систем разработки и тестирования.
[general]
info=misc
db.password=secret
db.host=localhost
[production : general]
info=only on production system
db.password=secret1
[testing : general]
info=only on test system
db.password=secret2
[dev : general]
info=only on dev system
db.password=secret3
Так dev:db.password == 'secret3', но dev:db.host == 'localhost', от исходной 'общей' группы.
'Производство', 'тестирование' и 'dev' могли быть именами хостов машины, или они - псевдонимы для них набор от некоторого другого механизма в сценарии управления конфигурацией.
Можно хотеть рассмотреть то, что разработчики не будут (И вероятно не был должен) иметь доступ к имени пользователя/паролям для производственной машины.
Для преодоления этого такая конфигурация должна считаться 'деталями развертывания', а не полной конфигурацией приложения. Даже когда Вы делаете это концептуальное различие, все еще необходимо иметь дело с различными средами развертывания, но, поскольку Вы, кажется, имеете дело с PHP, я не могу прокомментировать специфические особенности для Вашего случая.
Как Lars упомянул, одно возможное решение J2EE состоит в том, чтобы сохранить такие детали под JNDI, делая тот же самый двоичный файл приложения развертываемым на любой среде, оставив DBAs/Admins для установки имени пользователя/пароля для каждой машины.
Создайте шаблон для файла (например, config.php-значение-по-умолчанию) и позвольте пользователю скопировать шаблон. Она может также сделать разность для наблюдения то, что изменилось между версиями для слияния этих изменений в локально развернутую версию файла.
Некоторые возможные решения:
При использовании сервера приложений J2EE можно искать свойства через JNDI, существуют инструменты, чтобы легко установить и просмотреть их на сервере.
Вы можете иметь файл свойств по умолчанию в своем сервере подверсии, но посмотреть в другом месте на серверах (вне частей проекта, в которых зарегистрировались svn) для реального файла свойств, но затем Вы обычно получаете зависимые от операционной системы пути и должны не забыть обновлять реальные файлы свойств вручную, когда Вы добавляете новые свойства в своем svn файле.
Можно установить свойства в файле свойств как часть сборки и передать в параметре команде сборки для сообщения этого который серверная среда создать для. Это может чувствовать немного кольца, и необходимо не забыть обновлять сценарий сборки с новыми свойствами. Но это может работать хорошо - при установке Непрерывного Сервера интеграции это может создать для всех различных сред и протестировать пакеты на Вас. Затем Вы знаете, что у Вас есть что-то готовое развертывание.
На проектах я в настоящее время продолжаю работать, у нас есть 2 файла свойств для получения информации о схеме базы данных - один для продуктивной среды и один для разработки. У нас есть класс, который загружает все наши свойства для выполняемого модуля с логикой, которая определяет который файл загрузиться.
Так как наша среда разработки локально является файловой системой Windows, и рабочие серверы воздействуют на файловые системы UNIX, наше решение состояло в том, чтобы определить операционную систему хоста и загрузить корректный файл.
Мы сохраняем их непосредственно в рамках нашего управления исходным кодом для хранения истории любых изменений сделанной. Я думаю, что мы извлекли урок из наших (внутренних) клиентских взаимных упреков в отношении БЕЗУМНО ЧАСТЫХ ИЗМЕНЕНИЙ ТРЕБОВАНИЙ, в которых мы должны были смочь защитить любое из прошлых изменений в файлах.
Это может быть уникально для нашей ситуации, но я нашел, что это чрезвычайно полезно, особенно если я пытаюсь копировать тестовый прогон от предыдущего пересмотра.
Можно также сделать домен файла конфигурации зависевшим. Таким образом, можно создать конфигурацию для Вас локальная машина и для рабочего сервера (серверов). Действительно необходимо создать логику, конечно, для обработки этого.
При выполнении апачского веб-сервера, можно легко настроить его, чтобы иметь каждого разработчика, использующего их собственный (sub) домен на их локальном поле вместо того, чтобы просто использовать localhost. Таким образом, каждый разработчик может использовать их собственную конфигурацию.