Comments 17
в том числе и для каждого разработчика — своя личная
ИМХО — большой оверхед, гораздо лучше для Develop контура использовать переменные окружения.
Например, если есть ActiveDirectory, то каждому разработчику через групповые политики можно централизованно выставлять значения переменных окружений.
Если же AD нет, ну тогда один раз можно и занести в ручную или через скрипты задать в целевой системе разработчика.
В вашем случае имхо трансформация конфига должна применяться не в момент сборки, а в момент публикации.
Так же непонятно как вы в своем решении прячете продакшн конфиг, в котором могут содержаться боевые логины/пароли и т.д. если все это зашито в релизную трансформацию, то это тоже решение не очень.
Как выше заметили для решения таких проблем используются либо переменные окружением, либо сервисы которые в зависимости от 1 переменной окружения (dev|stage|prod) выдаст вам актуальную конфигурацию для приложения
по поводу LogEvent недавно прикрутили в нлог structured logging, хотя я все равно поклонник Serilogа
Поэтому для применения достаточно выбрать нужную solution configuration — либо как указано в статье, либо при создании publish-профиля.
Вопрос сокрытия секретных данных из web.config'а темы трансформаций не касается ну вообще никак. Замечу только, что есть техники, позволяющие шифровать куски web.config'а.
Ни для чего из этого переменные окружения не нужны.
Замечу только, что есть техники, позволяющие шифровать куски web.config'а.
Сталкивался я с такими техниками, больше не хочется.
Судя по иконке в SolutionExplorer файл NLog.config лежит в репозитории и наверное у него длинная история.
Подход с кофигом для каждого разработчика имеет недостатки:
• Надо следить за изменением конфигов во всех N трансформ файлах
• NLog.Prod.config лежит в репозитории и судя по всему со всеми паролями прод базы
• Плохо масштабируется и не работает для большого кол-ва разработчиков
• Не применить без боли в ASP.NET Core
Если проблема только в имени БД, возможно, проще всем использовать одно имя?
Посылать мейлы с локальной машины выглядит странновато, но ладно.
Но даже для решения этих двух проблем можно использовать:
• Environments variables
Для Core:
• https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-2.0
• Параметны командной строки
Как уже написали выше, конфиг не должен быть именным, это отражение окружения, которое у всех разработчиков должно быть одинаковое, ну или по крайней мере надо стремиться к этому.
"NLog.Prod.config со всеми паролями прод базы" — если вы в нлоге храните "все пароли", то ой, конечно. Излишне делать из хранилища логов что-то большее. Не хотите в nlog.config хранить логин-пароль к бд, если логи идут в бд — можно сделать пользователя sql server, имеющего право только на хп AddLog. А еще лучше тогда использовать Trusted Connection и доменную авторизацию — и это будет совсем ок для обычного проекта. Если и так опасно (я уверен, что это так для очень малой доли проектов — лишь самых больших и самых серьезных, для которых все по-другому. Даже есть такой афоризм — "лучшее враг хорошего"), или не хотите там светить настройками доступа к smtp — можно конфиг нлога
- хранить в web.config и там шифровать;
- хранить во внешнем файле, который будет присутствовать только в ФС ПРОДа — не хранить его в репозитарии. Для этого нужно использовать директиву include https://github.com/nlog/NLog/wiki/Configuration-file#include-files
Что хранить в web.config, и что не хранить статья не затрагивает. Статья ровно об оповещении об ошибках по-своему для каждого контура. Не хотите хранить чувствительные к безопасности данные — ну ок, можно их вынести. Тут замечания: во-первых, это нужно для очень малой доли проектов (да, у всего есть границы применимости) — обычно достаточно того факта, что web.config недоступен без доступа к файловой системе; во-вторых, любое решение по хранению настроек все основного их хранилища подразумевает дисциплинарное ограничение, а их гораздо полезнее заменять на инструментальные расширения. Я снова имею в виду, что части web.config можно шифровать.
http://qaru.site/questions/173916/how-to-encrypt-one-entry-in-webconfig
Утверждение "конфиг не должен быть именным" не является ни абсолютом, ни даже полезным для большей части проектов. Именной конфиг ничему, в обычном корпоративном проекте, не мешает. Тут я не имею в виду проекты, где разработчиков очень много — и опять же, это обычная ситуация. Даже для 10 разрабов не вижу проблемы. У разработчика запросто может быть — и это просто конкретные примеры из живых проектов:
- Именованный инстанс sql server'а, или он может использовать sql server на сервере, если, например, он на ноутбуке и у него не хватает ресурсов.
- Другое имя БД — а я хочу иметь возможность переключиться на восстановленный бекап, или, наоборот, на чистую БД без данных. Или вообще один sql server на всех, и тогда у всех имена БД должны быть разные. Предложение "давайте у всех имя БД будет одинаково" вредно. Кстати, весьма полезна практика иметь 2 sql server'а — ПРОД и тестовый, для экономии ресурсов. А на тестовом несколько БД для разных тестовых контуров, в том числе и для разрабов.
- Другие настройки включения-выключения фоновых сервисов. Если работает над одним сервисом, ему не нужно запускать весь контур.
- Другой урл для собственного веб-сервиса, эмулирующего внешнуюю ИС. Не надо запрещать это делать.
- Настройки собственной шины сообщений, своего rabbitmq.
- А если я хочу протестировать весь контур, то я хочу иметь все настройки, равные боевым, кроме всяких урлов.
Все это исключительно из моих работающих проектов, но я бы это обобщил — у каждого контура приложения должна быть возможность задать свое личное значение любой настройки. И работающий экземпляр приложения у разработчика в visual studio — это тоже контур. Вредно называть "окружением" значения настроек. Окружение — это набор всех сервисов (и, обычно, их версий), работающих "рядом". А настройки этих сервисов — не окружение. Тогда утверждение "окружение у всех контуров одинаковое" очень полезно и конструктивно.
"NLog.Prod.config со всеми паролями прод базы" — если вы в нлоге храните "все пароли", то ой, конечно.
Я как раз предлагал использовать подход где пароли хранятся не в репозитории. Ну и я не использую NLog)
можно конфиг нлога...
Понятно что можно шифровать, выносить в N отдельных файлов, убеждать себя и команду что хранить пароли от прода в репозитории это хорошо и надеяться что кто-нибудь по случайности не дропнет базу. Но ради чего все это? Чтобы получить систему которая не масштабируется и не работает с новыми технологиями (ASP.NET Core)?
Статья ровно об оповещении об ошибках по-своему для каждого контура.
Тут я не имею в виду проекты, где разработчиков очень много — и опять же, это обычная ситуация. Даже для 10 разрабов не вижу проблемы.
Стоит добавить: Для небольшой команды.
Ну то есть вы понимаете что ваш подход не масштабируется, и если вдруг ваша команда вырастет, то он не будет работать хорошо?
Именованный инстанс sql server'а, или он может использовать sql server на сервере, если, например, он на ноутбуке и у него не хватает ресурсов.
В sql server есть алиасы.
Кстати, весьма полезна практика иметь 2 sql server'а — ПРОД и тестовый, для экономии ресурсов. А на тестовом несколько БД для разных тестовых контуров, в том числе и для разрабов.
Опять же, немасштабируемое решение работающее для небольшой команды.
Другой урл для собственного веб-сервиса, эмулирующего внешнуюю ИС. Не надо запрещать это делать.
Согласен что нельзя, но какой довод в пользу уникального имени для каждого разработчика?
Все это исключительно из моих работающих проектов, но я бы это обобщил — у каждого контура приложения должна быть возможность задать свое личное значение любой настройки.
Даже если это так, то есть более удачные решения, которые указывали ранее, которые лишены недостатков которые есть в вашем подходе.
Вредно называть "окружением" значения настроек.
Почему вы так решили? Даже в документации МС разделение настроек идет по окружению.
Оповещение об ошибках: с каждого контура по-своему