ClearCase UCM - лучшие практики с использованием компонентов

Мы переносим довольно большую базу кода из VSS в Clearcase w\UCM и рассматриваем возможность организации нашего источника в один или несколько компонентов в рамках одного проекта. Какие лучшие практики\потенциальные подводные камни мы должны иметь в виду?

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

Ответ 1

Самая опасная ловушка:

Как только компонент определен, вы не можете перемещать элемент за пределами этого компонента (его можно скопировать и воссоздать в другом месте, но вы потеряете его историю)

Самая полезная передовая практика:

Хорошо понять природу компонента UCM: это о когерентности.
Компонент представляет собой набор файлов, который:

развивается как единое целое,
помечен как базовый, в целом,
является разветвленным в целом.

Если вы можете сделать эволюцию, не касаясь другой группы файлов, возможно, у вас есть два компонента.

Пример компонентов:

приложение (или автономная часть приложения)
техническая библиотека
пакетный набор файлов (для выпуска)

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

Когда все эти компоненты определены, у вас есть два подхода к управлению ими:

системный подход (каждый компонент доступен для записи в проекте UCM): полезно для запуска проекта, но громоздкий с унаследованным проектом: вам не нужно ставить базовую линию на каждый компонентов просто потому, что в одном из этих компонентов было изменено 3 файла.
компонентный подход: один или два записываемых компонента, остальное - только как немодифицируемый компонент. Это масштабируемый подход, позволяющий вам определить один проект для каждого компонента для разработки с "фиксированной конфигурацией" (то есть "другими базовыми линиями", представляющими фиксированные состояния немодифицируемых компонентов, которые необходимы для компиляции Модифицируемая. Вы можете в любой момент изменить эту конфигурацию, то есть вы можете переустанавливать базовые линии фундамента немодифицируемого компонента, когда захотите).

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

Помните: поток представляет собой процесс разработки.
Не вызывайте Stream после ресурса (например, VonC_stream), но после задачи или набора задач, которые необходимо выполнить в этом потоке (как в APP_LCH_R32_Dev: Разработка для 32-й версии моего приложения Launcher)

Примечание: UCM - это всего лишь некоторые метаданные поверх ClearCase: даже если группа файлов определена как компонент UCM, ничто не мешает вам создавать классические ветки, контрольные проверки или проверки (не в UCM) просмотров).

Существует ли опасность создания слишком большого количества мелкозернистых компонентов или слишком много зависимостей между компонентами?

Да, поэтому важна Аппликационная архитектура. Опять же, как только компонент определен, вы не можете перемещать элементы между этими компонентами.

Еще одна информация о компонентах - их макет:

myVob
  myComponent1
  myComponent2
  myComponent3

Корневой компонент всегда находится на первом уровне ниже Vob.
Вы также можете определить компонент как все Vob, но я бы не рекомендовал его (добавление Vob ставит ударение на ваш VOB-сервер. Добавление каталога в существующем Vob ничего не стоит)

Это означает, что если вы определите некоторые технические библиотеки как компоненты, вы не сможете:

myLibs
  Apache
    ant
    xalan
    xerces

но придется делать:

myLibs
  apapche_ant
  apache_xalan
  apache_xerces

Заключительное предупреждение: зависимость (истинный знак системы управления конфигурацией)

Одним из основных преимуществ UCM (или, как я думал, в то время - 2003) является зависимость.
Если A зависит от B, и я помещаю A в свой проект, он автоматически включит B в тот же проект.

Магия.

Но он сломан.

Во-первых, никогда не зависимо от корневой базы (корневой компонент - это набор файлов). Он будет разбит при первом перекрытии:

    A1
      B1
    B2

Здесь вам нужно B2 продолжить строительство A, но A начинается с A1 на основе B1: B2 переопределяет B1. Как только вы положите базовую линию на A (A2), она закончена. Вы больше не сможете менять B. A базовый уровень паразита (называемый A2!?) будет помещен в компонент (не изменяемый!) B из-за перекрытия.

Всегда включайте свои зависимости в безвирусном компоненте

    ADep1
      A1
      BDep1
        B1
    BDep2
        B2

Здесь у вас есть бескоронные компоненты ADep и BDep (rootless-компонент - это специальный компонент, который объединяет другие компоненты без корневого или корневого)

У вас все еще есть переопределение, но на этот раз между компонентами без корней.
Это все равно сделает базовый уровень паразита (на BDep, называемый A2), но по крайней мере вы сможете снова перегрузить BDep2 в другие базовые линии (BDep3, BDep4...)

Подробнее об этом Incoherences и несоответствия ClearCase UCM, Рациональные контр-аргументы здесь (и только после этого их сообщение, доказательство того, что их аргументы не очень хороши, чтобы сказать меньше).

Читайте также Как использовать функции Clearcases