Возможно ли частичное развертывание ASP.Net MVC?

Question

У нас есть приложение MVC 5, основанное на модулях (группа функциональных возможностей). У нас также есть команды, посвященные каждому модулю. Поэтому мой вопрос: Можно ли сделать частичное развертывание, где мы публикуем только те изменения, которые нам нужны?

Может быть лучше для меня, чтобы объяснить, как мы работаем сегодня:

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

Когда я использовал ASP.Net Webforms с другим проектом, мы обычно развертывали его на уровне страницы/кода, и это было просто отлично, но теперь все (контроллеры, помощники и т. Д.) Попадают в одну сборку, а также если мы измените что-то в папке Bin, которую AppDomain получает повторно, поэтому приложение в основном перезагружается.

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

Answer 1

Если у вас разные команды, работающие над одним и тем же проектом, вероятно, вы должны взглянуть на branch strategies. В вашем конкретном случае ветвь на каждую функцию (или на модуль) может работать нормально.

В вашем случае CI должен быть включен на «основной» ветке. Когда команда запускает функцию, они создают ветку. Во время разработки они берут на себя эту ветку (вы можете включить автоматическое выполнение теста и развернуть его на ветви «функции»). После завершения функции они объединяют изменения в «основные», CI создают сборку и развертывают ее на сервере. Однако есть один недостаток, возможные конфликты во время слияния, поэтому вам необходимо убедиться, что ваши команды будут связываться с основной ветвью как можно чаще, чтобы свести к минимуму эти проблемы.