Инструментов, позволяющих из двух описаний состояния сделать набор команд на приведение одного к другому («сгенерировать патч»), не то чтобы совсем нет, но они очень ограничены и примитивны.
Тихо-тихо, visual studio очень отлично это делает! =) Database project там очень хорошо работает.
"NLog.Prod.config со всеми паролями прод базы" — если вы в нлоге храните "все пароли", то ой, конечно. Излишне делать из хранилища логов что-то большее. Не хотите в nlog.config хранить логин-пароль к бд, если логи идут в бд — можно сделать пользователя sql server, имеющего право только на хп AddLog. А еще лучше тогда использовать Trusted Connection и доменную авторизацию — и это будет совсем ок для обычного проекта. Если и так опасно (я уверен, что это так для очень малой доли проектов — лишь самых больших и самых серьезных, для которых все по-другому. Даже есть такой афоризм — "лучшее враг хорошего"), или не хотите там светить настройками доступа к smtp — можно конфиг нлога
Что хранить в 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 — это тоже контур. Вредно называть "окружением" значения настроек. Окружение — это набор всех сервисов (и, обычно, их версий), работающих "рядом". А настройки этих сервисов — не окружение. Тогда утверждение "окружение у всех контуров одинаковое" очень полезно и конструктивно.
Я вот не замечаю ну никакого оверхеда.
А вот проблему, когда у одного разраба БД зовется по-одному, а на других контурах по-другому, видно очень хорошо.
Обычный publish Visual Stuidio применяет трансформации.
Поэтому для применения достаточно выбрать нужную solution configuration — либо как указано в статье, либо при создании publish-профиля.
Вопрос сокрытия секретных данных из web.config'а темы трансформаций не касается ну вообще никак. Замечу только, что есть техники, позволяющие шифровать куски web.config'а.
Ни для чего из этого переменные окружения не нужны.
Коллеги, большое спасибо за внимание, дельные комментарии, и отдельное спасибо тем, кто поделился своими подходами.
Я не претендую на знание всех инструментов — хотел бы попросить поделиться мнением тех, кто знает, насколько хорошо и что умеет MS Visual Studio Database Project? Лично я не пробовал, но априори как-то… не доверяю чтоли. Ни в коем случае не хочу это никому навязывать. Пока мне кажется, что он умеет что-то наподобие подхода 2, но со слишком большими ограничениями.
Так же очень интересно узнать чье-то практическое мнение про Datical и redgate Source Control.
вот =)
Тихо-тихо, visual studio очень отлично это делает! =) Database project там очень хорошо работает.
"NLog.Prod.config со всеми паролями прод базы" — если вы в нлоге храните "все пароли", то ой, конечно. Излишне делать из хранилища логов что-то большее. Не хотите в nlog.config хранить логин-пароль к бд, если логи идут в бд — можно сделать пользователя sql server, имеющего право только на хп AddLog. А еще лучше тогда использовать Trusted Connection и доменную авторизацию — и это будет совсем ок для обычного проекта. Если и так опасно (я уверен, что это так для очень малой доли проектов — лишь самых больших и самых серьезных, для которых все по-другому. Даже есть такой афоризм — "лучшее враг хорошего"), или не хотите там светить настройками доступа к smtp — можно конфиг нлога
Что хранить в web.config, и что не хранить статья не затрагивает. Статья ровно об оповещении об ошибках по-своему для каждого контура. Не хотите хранить чувствительные к безопасности данные — ну ок, можно их вынести. Тут замечания: во-первых, это нужно для очень малой доли проектов (да, у всего есть границы применимости) — обычно достаточно того факта, что web.config недоступен без доступа к файловой системе; во-вторых, любое решение по хранению настроек все основного их хранилища подразумевает дисциплинарное ограничение, а их гораздо полезнее заменять на инструментальные расширения. Я снова имею в виду, что части web.config можно шифровать.
http://qaru.site/questions/173916/how-to-encrypt-one-entry-in-webconfig
Утверждение "конфиг не должен быть именным" не является ни абсолютом, ни даже полезным для большей части проектов. Именной конфиг ничему, в обычном корпоративном проекте, не мешает. Тут я не имею в виду проекты, где разработчиков очень много — и опять же, это обычная ситуация. Даже для 10 разрабов не вижу проблемы. У разработчика запросто может быть — и это просто конкретные примеры из живых проектов:
Все это исключительно из моих работающих проектов, но я бы это обобщил — у каждого контура приложения должна быть возможность задать свое личное значение любой настройки. И работающий экземпляр приложения у разработчика в visual studio — это тоже контур. Вредно называть "окружением" значения настроек. Окружение — это набор всех сервисов (и, обычно, их версий), работающих "рядом". А настройки этих сервисов — не окружение. Тогда утверждение "окружение у всех контуров одинаковое" очень полезно и конструктивно.
А вот проблему, когда у одного разраба БД зовется по-одному, а на других контурах по-другому, видно очень хорошо.
Поэтому для применения достаточно выбрать нужную solution configuration — либо как указано в статье, либо при создании publish-профиля.
Вопрос сокрытия секретных данных из web.config'а темы трансформаций не касается ну вообще никак. Замечу только, что есть техники, позволяющие шифровать куски web.config'а.
Ни для чего из этого переменные окружения не нужны.
Для команды из 5 разработчиков никакого оверхеда.
Я не претендую на знание всех инструментов — хотел бы попросить поделиться мнением тех, кто знает, насколько хорошо и что умеет MS Visual Studio Database Project? Лично я не пробовал, но априори как-то… не доверяю чтоли. Ни в коем случае не хочу это никому навязывать. Пока мне кажется, что он умеет что-то наподобие подхода 2, но со слишком большими ограничениями.
Так же очень интересно узнать чье-то практическое мнение про Datical и redgate Source Control.