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

Единственная самая опасная ловушка:

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

Единственный наиболее полезный передовой опыт:

Разберитесь в природе компонента UCM: речь идет о согласованности.
Компонент - это набор файлов, который:

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

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

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

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

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

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

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

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

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

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

Примечание. UCM - это всего лишь некоторые метаданные поверх ClearCase: даже если группа файлов определена как компонент UCM, ничто не мешает вам по-прежнему создавать классические ветки, проверки или проверки, не относящиеся к 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 из-за перекрытия.

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

    ADep1
      A1
      BDep1
        B1
    BDep2
        B2

Здесь у вас есть компоненты без root ADep и BDep (компонент без root - это специальный компонент, который объединяет другие компоненты без root или root). У вас все еще есть переопределение, но на этот раз между компонентами без root.
Это все равно приведет к базовый уровень паразита (на BDep, называется A2), но, по крайней мере, вы сможете перенастроить BDep2 на другие базовые показатели позже (BDep3, _28 _...)

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

Прочтите также Как использовать возможности Clearcase