.NET Web Service Best Practice для нескольких разработчиков
У нас есть большой проект ASP.NET, состоящий из нескольких сотен отчетов. Мы находимся в процессе перемещения всех SQL-запросов (выполняемых в базе данных Oracle) в три веб-службы. Веб-службы классифицируются по командам, выборкам и запросам отчетов. Мы должны развернуть подмножество нашего проекта с использованием серверной части SQL * Server в нескольких местах, отключенных от Интернета. Следовательно, наличие всех подключений к базе данных и запросов в веб-службах делает приложение управляемым, и мы можем извлекать подмножество отчетов и не изменять код. Проект находится под контролем версий с использованием программного обеспечения Serena ChangeMan.
Проблема в том, что у нас есть несколько программистов, и всем им нужно проверять файлы веб-сервисов, чтобы работать над своими элементами. Мы только что реализовали ветвление, но оно постепенно превращается в кошмар. У нас есть ежемесячные поставки продукции, и иногда предметы, которые должны входить в ежемесячную сборку, задерживаются до следующего месяца. Слияние стало ручным процессом.
Я провел поиск в Интернете и удивился, что не смог найти ни одной хорошей «передовой практики» белых страниц архитектуры веб-сервисов. Вероятно, многие крупные компании столкнулись с этими проблемами.
Большинство крупных групп разработчиков используют ветвление? Я действительно читал, что Visual Studio Team System Database Edition может предоставить стандартный код, который позволит приложению подключаться к разным базам данных. Будет ли покупка Team System лучшим методом? Или кто-нибудь знает, где я могу найти документацию, которая поможет нам решить эти проблемы?
Спасибо, Лори
Ответы 3
Мы используем SOA, но мы также используем SVN, который больше ориентирован на слияние. Может быть, рассмотреть другую систему контроля версий?
Эта проблема, казалось бы, совершенно не зависит от цели программного обеспечения. Проблема здесь в том, что у вас есть небольшое конечное количество файлов, с которыми ежедневно будут работать несколько разработчиков. У меня нет опыта работы с программным обеспечением Serena ChangeMan или TFS, кроме как поиграть с ним. У меня есть опыт работы с парой систем контроля версий, которые используют модель слияния / фиксации: CVS и Subversion. Обе эти отличные бесплатные системы контроля версий широко используются.
Если вы не знакомы с моделью слияния / фиксации, идея состоит в том, что ни один разработчик не может «проверить» и заблокировать файл на предмет изменений. Каждый может скачать и внести изменения в любой файл. Когда пришло время зафиксировать эти изменения в базе данных исходного кода, программное обеспечение репозитория предотвратит фиксацию, если другие изменения были внесены в файл другим разработчиком. Затем загружается новая версия, и в большинстве случаев изменения автоматически объединяются с вашими изменениями. Вы повторно тестируете, а затем фиксируете эту версию. Эта модель очень удачная и очень масштабируемая.
Сказав все это, даже модель слияния / фиксации не может решить проблему небольшого количества файлов, когда множество разработчиков вносят изменения в указанные файлы. Я бы рекомендовал разделить вашу функциональность на большее количество веб-сервисов. Возможно, вместо трех монолитных веб-служб вы могли бы создать три группы связанных веб-служб. Я думаю, что это в сочетании с использованием системы контроля версий с объединением / фиксацией решит ваши проблемы.
Серверы CVS и Subversion работают в Windows, Mac и Linux. Для каждого существует несколько клиентов, доступных в нескольких операционных системах. К ним относятся автономные клиенты, плагины Visual Studio и плагины оболочки. Еще один плюс в том, что и CVS, и Subversion доступны из командной строки, что значительно упрощает создание сценариев (например, автоматическую сборку).
Почему бы не разделить вашу логику на отдельные файлы классов, которые может проверить каждый разработчик?