механизм доставки, Rational ClearCase - PullRequest
Новая
       10

механизм доставки, Rational ClearCase

2 голосов
/ 08 апреля 2010

Мы создали потоковую структуру для модели Rational ClearCase UCM.

Int  
-- Prd  
-- Uat  
-- Dev  
---- Development Stream r1.0

Недавно мы перенесли базу кода в новую настройку.У нас было три разных кодовых базы, т.е. три физических кодовых базы.

Процесс миграции:

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

На данный момент поток интеграции имеет самую последнюю базовую линию, то есть базовую линию разработки.
Теперь у нас есть два других потока для prd и uat, из которых будет выпущен релиз.быть сделано в соответствующих условиях.

Теперь у меня есть мой поток разработчиков.Я создаю деятельность и делаю некоторые изменения.Теперь мне нужно продвигать эти изменения в среде UAT.Если я внесу изменения в поток интеграции, объединение будет выполнено, но на основе разработки.Я не хочу перебазировать его в uat, так как многие приложения для разработки будут перебазированы в uat, что нежелательно.

Как мне добиться продвижения изменений в среде uat (поток uat).добрый совет.

1 Ответ

0 голосов
/ 08 апреля 2010

Похоже, ваша структура потока выглядит так: 

Int
  Dev
  UAT
  Prd

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

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

  • ежедневная разработка для Dev
  • тест в режиме «только чтение» для UAT (вы не должны ничего трогать, просто протестируйте и примите или отклоните)
  • Исправления в Prd

Int, чтобы записать последнюю базовую линию Prd, чтобы позволить другому проекту использовать одну из этих базовых линий в качестве отправной точки, избегая использования базовой линии, сделанной из ветви ветви ветви («каскадное ветвление»).

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

Int
  Prd
  Dev
    UAT
  • Вы перебазируете UAT с любой базовой версией Dev, которую хотите протестировать (таким образом, Dev может продолжать ежедневную разработку, не связываясь с контентом, тестируемым для пользовательских приемочных тестов)
  • Если базовый уровень, перебазируемый в UAT, соответствует ожиданиям, вы доставляете его непосредственно в prod (где могут появиться некоторые последние исправления)
  • Когда базовый уровень Prd установлен и стабилен, вы доставляете его в Int (для записи того факта, что это тот, который работает в Production
...