1

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

Таким образом, мы решили пойти на окружающую среду конкретного appsettings.ENVNAME.json

Как уже упоминалось в this answer мы следовали project.json -

"publishOptions": { 
    "include": [ 
    ... 
    "appsettings.json", 
    "appsettings.*.json", 
    ... 
    ] 
} 

Поступая, мы печатали appsetting.PROD.json к даже в разных средах TEST, что неверно.

Я понимаю, что мы можем контролировать загрузку AppSettings файлов в автозагрузку как this-

.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true); 

Но и в этом случае, другие файлы доступны. (Кто-то по изменению имени ошибки окр и она начнет подбирая детали другого окружения)

В настоящее время (в соответствии с нашей командой по аудиту), необходимо опубликовать среду конкретной appsettings.ENVNAME.json только соответствующую среду.

Как достичь этого с помощью project.json? Нужно ли нам писать для этого отдельный скрипт? Каков наилучший способ решить этот сценарий?

+0

_Кто-то по ошибке меняет имя env, и он начнет собирать информацию о других средах_, так же хорош, как и аргумент, как-то по ошибке публикует неправильный файл appsettings.envname.json, и он начнет собирать сведения о другой среде_, оба подвержены ошибкам ручного ввода того же типа. Вы можете сделать свой файл enviornment обязательным, а не необязательным в вашем примере. Если кто-то изменяет его на имя несуществующей среды, он сталкивается с ошибкой. Дело в том, что ваш пакет не должен решать, какой режим среды, но ваш сервер вы развертываете на – Tseng

+0

Даже если я сделаю это обязательным, другие файлы среды будут частью моей публикации. Аудиторская команда не одобрит это. Здесь мы намерены автоматизировать процесс публикации на основе имени среды. – Vishal26

+0

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

ответ

0

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

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

 Смежные вопросы

  • Нет связанных вопросов^_^