Есть ли пример двенадцатифакторного приложения с трюками специально для среды .NET/TFS?

Ответ 1

Я прочитал часть о конфигурации, и авторы явно не понимают использование файлов конфигурации в .NET. Проблемы, которые они выражают, являются проблемами, которые мы использовали для файлов .ini. Эти проблемы не существуют с .NET, потому что:

• Приложение "desktop" будет иметь один файл конфигурации для каждого развертывания. "app.config" будет существовать, как program.exe.config будет развернут в ту же папку, что и приложение.
• В веб-приложении иерархия файлов web.config будет существовать, опять же, в четко определенных местах и ​​с четко определенным именем.
• Функция преобразования web.config в Visual Studio 2010 позволяет проверить основной файл конфигурации в исходном элементе управления вместе с файлами преобразования, которые определяют, как автоматически редактировать основной файл для каждой конфигурации сборки (среды). Все эти файлы могут храниться в исходном элементе управления.
• В то время как по умолчанию учетные данные сохраняются в таких файлах (и, следовательно, проверены в контроле источника), это необязательно.
• Как минимум, в случае веб-приложений функция MSDEPLOY IIS вместе с веб-публикацией Pipeline Visual Studio 2010 позволяет параметризовать развертывание. По умолчанию это включает параметризацию строк подключения, одну из основных областей, где вероятны учетные данные. Это можно расширить, включив параметризацию всех учетных данных или других конфиденциальных данных, чтобы разработчики не имели доступа к этой информации. Параметры могут быть заполнены как часть процесса развертывания.

Ответ 2

12 Фактор имеет 3 "требования" для конфигурации.

• Не сохранять конфигурацию в коде
• Не помещайте свою конфигурацию в исходный элемент управления (или в формат, который, вероятно, попадет в исходное управление). Им нужна "единая кодовая база".
• Поместите свою конфигурацию в формат, доступный для любого стека технологий (.NET/Java/Ruby/.. и т.д.).

Я бы сказал, что файлы конфигурации .NET соответствуют половине из них.

• Файлы конфигурации не находятся в коде (pass).
• Файлы конфигурации не обязательно должны находиться в исходном управлении, но они часто оказываются там (сбой).
• Несмотря на то, что в формате XML и доступны другим технологиям, в конфигурационных файлах .NET есть много .NETisms. Схема конфигураций предоставляется типами .NET, поэтому Java-приложение не может проверить схему. (Половина кредита).

Хотя я могу согласиться с намерением их требований, я думаю, что их предложение переменных окружения является плохим предложением. Они выбрали переменные среды, потому что они рассматривают их как самый низкий общий знаменатель и доступны на всех платформах, но они действительно могут быть недоступны на всех платформах. Если вы используете веб-приложение с частичным доверием (общее на общей платформе хостинга), у вас может не получиться доступ к переменным окружения/набору среды.

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

Пока я вижу, что вы не хотите, чтобы секреты, хранящиеся в контроле версий, были доступны всем разработчикам. Есть определенно преимущества для версии, контролирующей вашу конфигурацию. Когда ваша производственная среда снижается из-за изменения конфигурации, легко спросить.. "что изменилось"? След аудита, оставленный кем-то, просто ssh'ing для машины prod и установка переменной окружения, может быть не так прост. Сказав это, я часто не сохраняю файлы конфигурации в той же части управления версиями, что и остальная часть кода. Я помещаю их в папку с ограниченной безопасностью, так что доступ нужен только нужным людям. Вы могли бы, возможно, сделать этот шаг дальше и поместить их в другой проект.

Я готов поспорить, что они нарушают свои собственные правила не устанавливать конфигурацию в файлы. Например. Первая маркерная точка на их домашней странице - "Использовать декларативные форматы для автоматизации установки, чтобы минимизировать время и затраты для новых разработчиков, присоединяющихся к проекту"; Я уверен, что все те настройки конфигурации, которые не должны быть в файле в любом месте, находятся в рецепте шеф-повара. Чтобы достичь цели автоматизации, вы должны где-то сохранить их в каком-то файле. И я был бы удивлен, если бы кто-то, кто потратил много времени на приготовление рецепта шеф-повара, не хранил его в контроле версий где-то.

Я думаю, что они могли написать страницу конфигурации по-разному и просто сказали, что ваша конфигурация отделена от вашего кода. Храните его в отдельных файлах (не вставляйте его в код) и храните его где-то отдельно (не помещайте его в один и тот же репозиторий). Ваш процесс развертывания приведет их обратно (код и конфиг) в один развертываемый пакет, но они должны быть раздельными до этой точки.

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

Ответ 3

Есть множество проблем с дизайном, который, по моему мнению, немного наив.

Например, в разделе "Резервные службы" говорится, что вы должны иметь возможность заменять хранилища данных без учета изменений кода.

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

Кроме того, не каждый хранилище данных поддерживает общий набор команд, так что вы можете легко переходить от одного к другому. Их конкретный пример использования MySql или CouchDB интересен тем, что эти две БД-системы концептуально отличаются друг от друга: одна из них является скорее традиционной РСУБД, другая - основанной на документах. Вы не можете просто взять свою структуру таблицы и применить ее непосредственно к CouchDB и ожидать, чтобы на нее набросились команды SQL.

Это означает, что вам нужно поставить переднюю часть на место, чтобы по существу перенести каждый конкретный хранилище данных с помощью набора команд, открытых как веб-сервис... Что, imho, делает разработку намного сложнее для очень небольшого (если есть) выгода.

Теперь, если они ограничивают возможность обмена подобным сервером (локальным mysql) на удаленный (Amazon RDS), то требование о том, чтобы ресурсы хранилища данных были доступны через URL-адрес, не имеет значения. Кроме того, требование о том, чтобы никаких изменений кода не происходило для этого перемещения, не является необходимым, так как вам не нужно менять код только для поддержки того, что ваша конкретная БД работает на другом сервере.

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

Ответ 4

Я думаю, что, следуя их указаниям на платформе Microsoft Windows, нужно хорошо понимать платформу.

Следуя примеру 3-го фактора, предлагая сохранить конфигурацию в среде, мы должны спросить себя, какие именно переменные среды на платформе Windows. Ответ - это реестр Windows. Теперь я занимаюсь разработкой серверного приложения, использующего реестр Windows, и учитывая мою роль (я забочусь о непрерывной интеграции, сборке и установщиках), я действительно ненавижу с мерой, которую мы должны используйте реестр Windows, но это то, что вы делаете на платформе Windows.

Реестр Windows, очевидно, терпит неудачу на стандарте языка и ОС, но даже если вы прибегаете к использованию простых переменных среды ванили, на платформе Windows эти реализованы в ключах реестра Windows.

Я время от времени совершаю грех хранения учетных данных в SCM (кстати, в последние годы в основном TFS), но никогда не для самого приложения, в основном для инфраструктуры построения (т.е. того, что никогда не будет развертываться на клиентских сайтах или в развертываниях и полностью отделяется от кода приложения).

Вы можете использовать приложение /web.config для хранения учетных данных (есть также функции шифрования), но в целом это плохая идея.

Кроме того, если вы используете базу данных как базовую (реляционную, не реляционную, любую базу данных на самом деле), некоторая конфигурация вполне может закончиться там, какая-то конфигурация может быть еще более удобной для хранения там (т.е. на мульти что вы действительно хотите изолировать конфигурацию, связанную с арендатором, и чаще, чем не общая конфигурация, в конечном итоге сосредоточена в специальном магазине арендатора 0), если вы можете хранить и извлекать (то есть в реестре) ключ для открытия дверь, которая приведет вас туда.

О втором вопросе, будучи новичком в манифесте 12factor (но из того, что я мог прочитать до сих пор, а не с базовыми понятиями), я не смог бы дать вам в этот момент предложение для эталонной архитектуры на .Net.

ОБНОВЛЕНИЕ 2-го вопроса

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

Такие вещи, как Windows Installer и инструменты для создания установочных файлов более высокого уровня (Wix, InstallShield,..), на самом деле не сопоставимы с RubyGems или CPAN, а NuGet еще не существует с точки зрения популярности.

Вы можете искать ссылочную реализацию, смотрящую на каналы NuGet, даже если авторы не знали о 12factor, манифест запрашивает довольно разумные вещи, хорошие разработчики в основном будут следовать за этими или очень похожими концепциями.

В качестве примера такого подхода я бы посоветовал вам взглянуть на Ayende RavenDB, вы можете получить его через NuGet, и я подозреваю, что это отметьте наиболее, если не все, коробки парных 12факторов (intro, features и исходный код).