Плюсы и минусы стратегий управления версиями веб-сервисов

Обновление 20100224 Мне действительно не нужны какие-то неубедительные определения с какого-то веб-сайта поставщика. То, что я ищу, — это практическая реализация и проблемы, с которыми сталкиваются в ежедневном цикле ИТ / бизнеса для людей, которые действительно внедряют этот материал.

Далее следует больше материала:

Стратегия выхода на пенсию не создана/не принята: Очевидно, ее необходимо создать. Меня интересует, как вы создаете эту стратегию и продаете ее руководству. Каковы все затраты/выгоды, на которые вы смотрите? Проводите ли вы анализ BE требований клиентов к перекодированию в сравнении с требованиями внутренней поддержки? Присваиваете ли вы значение $ внутренним расходам на поддержку древних API?

Последствия для производственной ИТ-поддержки: как вы работали со своими производственными ИТ-группами для развертывания своей стратегии. Что им нравится и что сводит их с ума?

Программное обеспечение: что любите делать ребята из программного обеспечения, что им говорит бизнес и что они на самом деле делают? Что работает лучше всего для них?

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

DBA: Как ваши администраторы баз данных справляются с общими процедурами, которые имеют решающее значение для регистрации данных для добавления поля в ответ xml? У вас есть один процесс или вы делаете разветвления и сегменты на основе схемы или чего-то еще?


оригинальная заметка

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

Я ищу плюсы и минусы для поддержки независимых автономных или нескольких / интегрированных версий с течением времени и как это влияет на бизнес, включая ресурсы поддержки разработчиков / интеграции разработчиков, производственную ИТ-поддержку, программное обеспечение, QA и DBA.

Любое понимание, опыт, ресурсы или идеи приветствуются.


person matt    schedule 21.02.2010    source источник


Ответы (1)


Веб-сервисы в нашем приложении — это всего лишь внешний интерфейс для бизнес-логики.

Новая версия веб-сервиса появляется в связи с изменением бизнес-логики. Когда вводится новая версия веб-сервиса, она размещается под новым URL-адресом. Например:

ver1 /websvc
ver2 /websvc2

Между уровнем веб-сервиса и бизнес-уровнем существует специальный код. Этот уровень обрабатывает различия в версиях веб-сервисов и передает вызов на последний бизнес-уровень.

Задача специального фасадного кода (между веб-службой и бизнес-логикой) — знать различия версий веб-службы.

person Vadym Stetsiak    schedule 03.03.2010
comment
Управление версиями на основе URL-адресов также позволяет вам запускать несколько версий бизнес-уровня параллельно на разных веб-сайтах (хотя это может вызвать проблемы в других местах), а также позволяет вам использовать журналы веб-сервера, чтобы увидеть, кто все еще использует старые версии. - person Neal; 04.03.2010