Относительно сбоя сборки в потоке интеграции и его исправления в среде UCM Clearcase

У нас есть хорошая система UCM Clearcase. У нас есть надлежащие ночные сборки потока интеграции, и я настроил CruiseControl.NET для различных сайтов.

Проблема в том, что в случае сбоев сборки базовый уровень не применяется. Это заставляет разработчиков исправлять проблемы на самом сервере сборки.

Это крайне нежелательно. Я хочу применить базовый уровень и сделать его *ОТКЛОНИТЬ*ed. Затем попросите разработчика исправить проблемы, перебазировав базовый уровень REJECTed.

Как мне это сделать в следующей конфигурации потока:

MainStream

    |
    |---Germany_Stream
           |
          / \
          Multiple developer streams
    |
    |---USA_Stream
           |
          / \
          Multiple developer streams

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

Затем эти изменения передаются в MainStream. Там происходит ночная сборка. Базовый уровень должен быть применен к MainStream и рекомендован на случай, если сборка пройдет успешно. Если это не удается, необходимо применить базовый план и *ОТКЛОНИТЬ*. Как сделать базовый план *REJECT*ed доступным разработчикам, которые находятся на два уровня ниже основного потока?

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


build clearcase-ucm
person msiyer    schedule 30.01.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Если вы думаете о перебазировании, вам нужно будет перебазировать поток сайта (США или Германия), затем перебазировать потоки разработки.

Это может быть хорошим подходом, поскольку каждый поток может выбрать перебазирование (подход pull) из потока сайта в свой поток разработки.
Единственная проблема заключается в том, что для этого требуется слияние в потоке (США или Германия), который также используется. разработчиками для доставки: могут возникнуть конфликты.

Я бы порекомендовал создать подпоток к Main с именем Rejected_Stream, который можно перебазировать по желанию (и он получит последнюю базовую версию REJECT).
Оттуда любой разработчик может инициировать доставку из этого потока в свой собственный поток разработки. .

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

person VonC    schedule 30.01.2013
comment
Спасибо VonC. Каковы наилучшие методы или методы, когда дело доходит до исправления проблем сборки в основном потоке? Разработчики, исправляющие проблему на сервере сборки, в любом случае могут оказаться бесполезными, поскольку это излишне открывает сервер для разработчиков и, что более важно, портит историю файла. - person msiyer; 30.01.2013
comment
@msiyer проблема заключается в распространении исправлений, сделанных на Main. То, что исправлено в Main, может больше не иметь значения для разработки, которая могла развиваться по-другому. Предоставление разработчику возможности видеть, что нужно исправить, через базовый уровень REJECT в выделенном потоке), сохраняя при этом односторонний механизм доставки (dev=›site=›Main), что позволяет упростить историю. - person VonC; 30.01.2013
comment
Мой пост и комментарии основаны на логических предположениях, которые я сделал после просмотра FLOW of CODE в UCM в течение нескольких месяцев. Я чувствую, что сделал правильные предположения. Спасибо VonC. Вы всегда были маяком надежды для этого одинокого рейнджера в джунглях темного кода :) - person msiyer; 30.01.2013