Лучшие практики для организации структуры / запуска "сборок" на большом решении - PullRequest
Новая
       6

Лучшие практики для организации структуры / запуска "сборок" на большом решении

3 голосов
/ 20 мая 2009

Я делаю очень большое веб-приложение (в настоящее время на 70 проектов и 150 тыс. Лок, но с гораздо большим количеством дел).

Я использую FinalBuilder для запуска сценариев сборки. Однако, каковы лучшие практики для структурирования такого большого проекта? А как насчет зависимостей сборки? Как влияет структура моих проектов на производительность кода (если есть)?

Я видел несколько предыдущих тем по этому поводу, но не могу их найти. Я видел потоки о решениях, превышающих 600 проектов в решении, ради четких ответов, давайте представим, что эта система вырастет до такого размера (я хотел бы знать, как организовать проект больше, чем тот, который у меня получится, поскольку это означало бы, что я могу организовать меньшее решение).

Если это имеет значение, система в основном находится в .NET 3.5 (C #, LINQ, SQL Server и т. Д.), Но также будет использовать Python / Erlang.

Ответы [ 3 ]

3 голосов
/ 20 мая 2009

У меня всего 40 проектов (но несколько миллионов локальных), и основные рекомендации, которые у нас есть:

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

Таким образом:

  • разработчики работают и компилируют свой код непосредственно в зависимости от поставок других проектов, от которых они зависят (в отличие от загрузки исходных текстов других проектов и перестройки всего локального).
    У них есть только правильные поставки, потому что они знают о своих зависимостях (как непосредственных, так и переходных)
  • тестеры могут быстро развернуть набор доставок (из глобального списка меток) для выполнения различных тестов (не регрессионные, стресс-тесты, ...)
  • Управление релизами может развертывать эти поставки (после окончательной глобальной сборки) на подготовительных и производственных платформах

Идея состоит в том, чтобы:

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

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

2 голосов
/ 20 мая 2009

Рассматривали ли вы использование NMaven и превращение каждого из 70 проектов в модуль? Это позволит вам контролировать сборку, упаковку, управление версиями и выпуск отдельных модулей и родительского проекта в целом. Это также поможет вам разрешить зависимости между различными модулями, внешними библиотеками и даже версиями и различными областями жизненного цикла (например, вам нужен только NUnit во время жизненного цикла тестирования, но не нужно его упаковывать в сборку).

Это может помочь более подробно объяснить, как эти проекты выглядят и как они зависят друг от друга.

1 голос
/ 20 мая 2009

Немного открыт как вопрос. Давайте начнем с базовой структуры, которую я предлагаю в качестве отправной точки для моих клиентов, внутри моей ветки

  1. Сценарии сборки
  2. Зависимости сборки - что нужно установить на машине сборки
  3. Библиотеки - LIB, DLL, ... прямые ссылки из проектов
  4. Источники документации - справочные источники
  5. Источники
  6. Развертывание сценариев

тогда Источники организованы в

  1. Admin - консоль администратора и скрипты
  2. База данных - схемы, скрипты, исходные данные
  3. Общее
  4. Web
  5. NTServices
  6. Услуги - REST / SOAP услуги
  7. BizTalk - вы называете вещи, характерные для продукта
...