Каков наилучший способ управления выпуском программного обеспечения с несколькими версиями?

Question

Моя компания создает веб-приложение для учреждений недвижимости - изначально написанное на классическом ASP с постепенным переходом на .NET.По сути, это веб-сайт с внутренней БД, смешанный с пользовательскими службами Windows / DLL.Довольно стандартный для приложений .NET.

В моих прошлых компаниях у нас был традиционный жизненный цикл разработки программного обеспечения.Мы создавали выпуски наших продуктов, и когда мы выпускали, ВСЕ клиенты получали такой же код .Требования к продукту были отфильтрованы нашей инженерной командой, отправлены в QA для тестирования в локальных промежуточных средах, а затем отправлены в производство.

Эта компания имеет несколько версий нашего продукта для нескольких клиентов.По сути, клиент A может быть в версии 1.5, клиент B в версии 1.6 и клиент C в версии 2.0.Мы делаем это потому, что учреждения, использующие наше приложение, предъявляют строгие требования ко всем изменениям, затрагивающим их пользователей.Если с выпуском 1.5 клиент доволен, он остается там, хотя в выпуске 2.0 есть все последние навороты.Клиенты фактически отодвигают процесс обновления, потому что новые «функции» фактически наносят ущерб их пользовательской базе, вызывая путаницу.

Поддержка такого типа жизненного цикла - это хорошо, когда вы маленький, но по мере того, как вы становитесь десятками или сотнямиклиентов, это нагрузка на наших DEV, DBA, QA, не говоря уже о нашей команде поддержки.Сейчас мы находимся в ситуации, когда мы можем запланировать только 6-8 сайтов в неделю, которые могут обновляться по мере поступления требований. Это заставляет нас заставлять другие сайты ждать 2-4 месяца, чтобы получать даже незначительные обновления на своих сайтах.Любая производственная проблема или ошибка, которая требует немедленного внимания, еще больше осложняет ситуацию - потому что сайт, на который уже запланировано получение обновления, должен быть расставлен по приоритетам, чтобы выделять время.

Извините, что это так долго, но ЛЮБАЯ помощьценится.Чем раньше мы внесем некоторые изменения, чтобы улучшить график выпуска, тем лучше.Спасибо!

Answer 1

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

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 на папку новой версии, нам не нужно беспокоиться об обновлении строк подключения или любых других данных, специфичных для клиента. Что делает это сложным, так это то, что каждое изменение оценивается с учетом того, будет ли каждый клиент хотеть это изменение одинаково или нет. Если нет, то должен быть способ отключить (или не устанавливать) это изменение.

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

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

Answer 2

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

Answer 3

Как я вижу, у вас есть два варианта:

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

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

Я думаю, вы могли бы сделать это следующим образом:

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

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

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

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

---

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

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