Оказывается, я работаю точно в той же среде. Вот как мы настроили нашу систему:

1. У каждого клиента своя база данных. Фактически вы обсуждаете мультитенантное решение. Несмотря на то, что использование одной базы данных для управления всеми ими имеет свои преимущества, это становится проблематичным, когда вы хотите переместить клиентов, или когда клиенты хотят разместить свои собственные системы, или когда у вас есть различия в схемах между версиями (что является обычным явлением). Единственный другой подход к этой проблеме - использовать одну базу данных, но сегментировать по имени схемы (например, ClientA.Table1, ClientB.Table1 ...).

2. Мы используем единую кодовую базу. Мы используем виртуальные каталоги, чтобы указать версию кода, которую использует клиент. Все клиенты в одной сборке указывают на одни и те же биты. Однако у нас может быть несколько версий в дикой природе. Таким образом, один клиент может указывать на 1.0.0.0, а другой - на 1.0.1.1.

3. Когда мы хотим кого-то обновить, мы указываем его виртуальный каталог на запрошенную выпущенную версию. Физические папки названы в соответствии с их полным названием версии (например, 1.0.3.4). Приложение предназначено для обнаружения несоответствия между ожидаемой версией базы данных и имеющейся у нее версией. Если есть разница, он перенаправляет на страницу, где администратор может обновить схему базы данных. Все изменения в базе данных оформляются сценариями и предназначены для выполнения в надлежащей последовательности. Мы используем третий октет номера версии, чтобы указать версию базы данных. Итак, 1.0.1.1 означает, что схема базы данных изменилась с 1.0.0.0.

4. Может возникнуть вопрос: «Зачем использовать виртуальные каталоги?» Это входит в основное правило разработки: код приложения не может включать какие-либо данные или настройки, специфичные для клиента. В частности, ничто из корня папки приложения не может быть специфичным для клиента. Итак, что насчет строк подключения? Вот почему мы используем виртуальные каталоги. Наша виртуальная установка выглядит примерно так:

clientsite (or vdir)
    /appname_vdir

Корневая папка клиентского сайта содержит файл web.config с любыми настройками клиента, не связанными с базой данных, такими как строки подключения. Когда мы указываем /appname_vdir на папку с новой версией, нам не нужно беспокоиться об обновлении строк подключения или любых других данных, специфичных для клиента. Что делает это сложным, так это то, что каждое изменение оценивается в свете того, будет ли каждый клиент желать этого изменения одинаково или нет. Если нет, то должны быть средства для отключения (или отмены установки) этого изменения.

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

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

На мой взгляд, у вас есть два варианта:

• размещать все версии самостоятельно и разумно различать, какую версию должен использовать клиент
• заставить клиентов размещать приложение самостоятельно

Хостинг самостоятельно

Думаю, вы могли бы сделать это так:

• установить все разные версии, которые используются в настоящее время
• есть один домен, каждый клиент получает его поддомен. Клиент ABC входит в abc.mydomain.com и т. Д.
• используйте механизм перенаправления или перезаписи URL, чтобы незаметно перенаправить их на соответствующую версию вашего продукта.
• когда клиент хочет выполнить обновление, перенести свои данные на более поздний экземпляр продукта и изменить правило перезаписи для своего поддомена

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

Клиентский хостинг

Это может быть относительно просто. Вы можете упаковать часть приложения ASP.NET в установщик MSI, создание виртуальных каталогов и пулов приложений и т. Д. Может быть выполнено из MSI. Затем вы можете использовать инструмент обновления базы данных, такой как DBGhost, для упаковки вашей базы данных - он берет вашу шаблонную (исходную) базу данных, сравнивает ее с целевой, а затем генерирует DDL, необходимый для приведения цели в соответствие с источником. Я понимаю, что для этого также есть инструмент, включенный в одну из версий VS2010, но я не использовал его и не могу его комментировать.

Вы, разработчики, можете облегчить многие проблемы с обновлением, предоставляя обновления в службу поддержки в удобной для них форме. По возможности используйте пакеты MSI. По возможности используйте инструменты создания / создания базы данных промышленной прочности. Если по какой-то причине вы не можете использовать инструмент обновления базы данных, убедитесь, что обновления базы данных написаны правильно (например, если объект существует, то измените else create). При необходимости укажите путь обновления, которому необходимо следовать - если клиент хочет перейти с 1.6 на 2.0, то сначала он должен пройти через 1.8 - это делает обновления более детализированными, предсказуемыми и простыми в управлении (вы поддерживаете сценарий обновления для 1.6. -> 1.8 и 1.8-> 2.0, вам не обязательно иметь его для 1.6-> 2.0).

Я надеюсь, что это дает вам достаточно, чтобы подумать - если у вас есть больше деталей, отредактируйте свой пост и добавьте их.

Задумывались ли вы об автоматизации обновлений и развертываний приложения. Если вы сможете придумать стандартизированный способ упаковки приложения независимо от версии, его будет очень легко автоматизировать с помощью такого инструмента, как Nolio ASAP (http://www.noliosoft.com). Это позволит вам создать процесс развертывания для каждой версии или даже для каждой учетной записи, а также включить «почти такие же» развертывания, где различия могут быть введены в качестве входных данных для каждого развертывания.