Развертывание распределенной системы .net с несколькими решениями. - PullRequest
Новая
       10

Развертывание распределенной системы .net с несколькими решениями.

0 голосов
/ 29 ноября 2010

У нас есть распределенная система .net, которая состоит из нескольких решений, каждое из которых имеет различные требования к конфигурации и развертыванию.В настоящее время весь код находится в одном проекте TFS, и каждое решение имеет свою собственную сборку.Они настроены для запуска изменений в этой папке управления исходным кодом решения.

Мы переходим в Team City, Git и Rake (из-за простоты ветвления и стоимости лицензий) и поэтому пересматриваем весь процесс сборки и имеемне удалось найти хорошую информацию по этому вопросу.Проблемы, которые мы пытаемся решить:

  1. Должны ли мы иметь отдельные сборки или одну большую сборку?Все решения должны быть построены и развернуты для функционирования системы, но приятно иметь небольшие сборки, так как они быстрые и простые в отладке.Некоторые решения более «автономны», чем другие.Наша текущая практика состоит в том, чтобы ставить в очередь все сборки, когда мы хотим развернуть их в тестовой или производственной среде, но иногда мы просто ставим в очередь отдельное решение, если это все, что изменилось.

  2. Должны ли мы хранить все решения в одном репозитории или у нас должен быть репозиторий для каждого из них?Мы используем несколько общих проектов и библиотек, как они будут работать с отдельными репозиториями?

1 Ответ

0 голосов
/ 29 ноября 2010

Существует множество различных способов хранения репозиториев, выполнения сборок и развертывания экземпляров.И многие из них правы.Из моей практики не важно, какую технику вы используете и какой инструмент для сборки и развертывания.Поэтому важно задавать вопросы, которые влияют на эти процессы:

  • , чтобы предотвратить путаницу решений / проектов, которые могут быть разделены (как отдельные). Если проект совместно используется несколькими решениями, лучше создать для него отдельный репозиторий.И просто добавьте к этому отношения из зависимых решений / проектов:
  • , чтобы предотвратить проблемы при создании различных сборок для разных целей (другими словами, Управление конфигурацией). Вы можете настроить TeamCity для этого (в основном для автоматизации сборки и развертывания после каждого 'коммита' или графика на основе времени) или использовать простую, но мощную утилиту, например, NAnt с предопределенными конфигурациями.

Так что я не вижу причин делать одну большую сборку (может быть только в выпуске), но отдельные сборки было бы проще использовать (для QA и разработчиков, которые работают только над какой-то частью).Второй вопрос - это время.Например, чтобы сделать полную сборку со всеми проектами в одном решении, требуется около 10 минут на процессоре Quad CPU 8 ГБ, но для сборки со счетной частью или частью регистрации всего 1 минута - это важно для меня.Просто попытайтесь представить себе этот процесс, нарисуйте лист бумаги, и станет понятно - что делать и зачем.

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

...