В данной лекции подробно рассматриваются принципы разработки масштабных проектов с использованием TFS. Как правило, отличие большого проекта от небольшого состоит в следующем:
Например, в большом проекте может понадобиться поддержка нескольких ветвей, чтобы различные группы могли параллельно разрабатывать разные функции. В этом сценарии, вероятнее всего, придется работать с зависимостями между решениями и проектами, совместно используя веб-службы и базы данных. Каждой группе, возможно, придется работать с собственным сервером сборки и выкладывать сборки в определенное место накопления.
Эта лекция адресована тем, кто участвует в управлении, поддержке и работе над крупномасштабными проектами. Рекомендации по работе с большими проектами можно также найти в лекциях 3, 5 и 7. В этой лекции все рекомендации по работе над большими проектами сведены воедино.
На рис.10.1 представлена типовая схема совместной работы нескольких подгрупп над созданием сложного приложения и проиллюстрированы ключевые моменты работы в большом проекте:
При работе над большим решением, включающим десятки проектов, могут возникнуть проблемы с его масштабируемостью решения ( .sln ) Visual Studio. В этом случае следует распределять управление версиями по подсистемам или подприложениям, используя несколько файлов решений и не создавая главного решения для всего приложения. На рис.10.2 продемонстрирован подход с использованием нескольких решений, который обычно применяется в больших группах.
В этом сценарии все ссылки внутри решения являются ссылками на проекты. Ссылки на проекты вне решений (например, на библиотеки сторонних производителей или проекты другого решения) являются файловыми ссылками. Это означает, что можно обойтись без "главного" решения, используя вместо него сценарий, "понимающий" порядок сборки решений.
Одна из главных задач при обслуживании структуры с несколькими решениями - обеспечить отсутствие циклических ссылок между решениями, что требует сложных сценариев сборки и явного отображения зависимостей. При такой структуре невозможно целиком собрать приложение в Visual Studio ; приходится прибегать к TFS Team Build.
Подробнее о подходе с использованием нескольких решений рассказывается в лекции 3.
В больших группах часто используется ветвление, как по группам, так и по компонентам. Кроме того, одна или несколько ветвей создаются для интеграции внешних зависимостей. Поскольку структура ветвления в больших группах более глубока, увеличивается промежуток времени между изменением в коде ветви разработки и переносом этого изменения в главную ветвь. Поэтому, создавая ветви, необходимо особенно тщательно продумывать стратегию слияния.
Выбирая между выполнением слияния по графику или под управлением событий, учитывайте следующие соображения.
Необходимо найти компромисс между стратегией ветвления и слияния и предполагаемой частотой выполнения сборок. Глубокая структура ветвления приводит к более продолжительному интегрированию дочерних ветвей в главную ветвь исходного кода. Признаки неверного выбора стратегии ветвления таковы:
Если в вашей команде возникли эти проблемы, подумайте об уменьшении глубины структуры ветвления. Ниже приведен пример структуры ветвления в большой группе:
В эту структуру включены:
Скорее всего, в больших группах и время сборки также будет большим. Интервал между сборками при использовании непрерывной интеграции должен быть больше продолжительности одной сборки, чтобы не создавать очередь и не перегружать сервер сборки. Система сборки в большой группе обычно организована следующим образом:
Другой ключевой вопрос: нужно ли выполнять сборку, тестирование и контроль качества в каждой точке интеграции? Все это можно отложить до объединения всех изменений в главной ветви интеграции. Идеальный вариант: использовать для каждой ветви отдельный сервер сборки, а также пороги качества, группы разработки и тестирования. Однако в случае отсутствия одной из составляющих для упрощения структуры можно отказаться от контроля качества или удалить некоторые ветви.
При работе с большими решениями, включающими десятки проектов, могут возникнуть проблемы с масштабируемостью решения (.sln) Visual Studio. В этом случае следует разбить структуру системы управления версиями на подсистемы или подприложения и использовать несколько файлов решения.
В больших группах структура ветвления более сложная, поэтому следует готовиться к увеличению задержки между внесением изменений в ветвь разработки и их распространением в главную ветвь.
Время сборки в больших группах обычно больше. Периодичность сборки при использовании непрерывной интеграции должна быть меньше длительности сборки. Это позволит избежать больших очередей сборок и перегрузки сервера сборки. Если проблемы с производительностью сервера сборки все равно сохраняются, рекомендуется использовать отдельный сервер сборки для каждой ветви системы управления версиями.