Clearcase UCM - Как работать с потоками и компонентами?

Question

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

Я утверждаю, что это неправильно, а не то, как предполагалось использовать UCM, но мне нужен был кто-то, более знакомый с UCM, чтобы подтвердить мои убеждения.

Я считаю, что потоки должны создаваться с функциональной точки зрения (хотя каждый пакет выполняет определенную функцию, несколько архитектурных пакетов способствуют выполнению некоторой функции клиента, назовите ее «ABC»). Затем компонент для каждого архитектурного компонента, который выполняет начальную разработку для функции "ABC", добавляется в поток. Все разработчики функции «ABC» теперь работают в потоке (или в некотором наборе дочерних потоков), чтобы завершить эту функцию. После завершения у вас есть базовая линия для каждого компонента UCM, и с точки зрения UCM не существует «связывания» между компонентами (кто-то утверждал, что это может так или иначе произойти в UCM из-за записей активности).

ПРИМЕЧАНИЕ. Я согласен с тем, что, возможно, вы не работаете таким образом НАВСЕГДА, но во время первоначальной разработки, когда интерфейсы обычно меняются, вы не реализовали все интерфейсы для всех функций, и поэтому несколько компонентов, работающих вместе в потоке, самый смысл. Позже вы можете перейти к «архитектурно-ориентированному на пакет» способу работы, при котором каждый пакет не зависит от изменений в другом.

Мысли? Извините за длинный пост, я чувствовал, что детали были необходимы.

Answer 1

Я согласен с VonC. Я бы предпочел функциональный подход.

Существует плагин ClearCase, который может помочь вам создать среду для ваших пользователей (поток, представления, стратегию проекта) независимо от вашего подхода. Просто гуглите про "clearEnv"

Answer 2

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

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

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

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