Управление параллельной разработкой с помощью IBM Rational Team Concert. Часть 2

Подключение пользователей к потокам

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

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

Создание новых рабочих пространств было описано в предыдущем разделе. Подключение рабочего пространства к различным потокам для передачи наработок описывается в следующем разделе.

Изменение целевого потока для передачи данных

В сценарии, показанном на рис. 2, разработчик внес изменения в функциональный поток 1. Этот массив изменений может содержать несколько файлов и, в соответствии с принципами выполнения проекта в среде Rational Team Concert, он либо имеет описание, либо идентифицируется, как элемент потока операций. Изменение содержания файлов выполняется на локальном жестком диске разработчика, а затем регистрируются в серверном архивном рабочем пространстве, при этом все изменения собираются в массив изменений, как показано на рис. 3. После этого изменения передаются в конкретный поток. В сценарии, показанном на рис. 15, пользователи Марк и Симон поставляют свои изменения в главный поток разработки, но Адриан передает свои изменения в функциональный поток 1. Целевой поток для операции поставки является одной из характеристик архивного рабочего пространства разработчика, как показано на рис. 17 для пользователя Марк.

Рис. 17. Свойства архивного рабочего пространства

Информационный раздел архивного рабочего пространства показывает несколько пунктов с полезной информацией. В соответствии с текущей решаемой задачей он содержит целевой объект для архива, который указывает, в какой поток будут посланы массивы изменений. Для того чтобы изменить целевой объект, выберите опцию Add (в разделе целевого объекта на экране) и затем выберите требуемый поток. Если пользователь с именем Марк хочет передать массивы изменений в функциональный поток 2, а не в главный поток, раздел целевых объектов будет выглядеть так, как показано на рис. 18.

Рис. 18. Добавленный альтернативный целевой объект (но не выбранный)

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

Рис. 19. Добавленный альтернативный целевой объект (и установленный как текущий)

Позиция, изображенная на рис. 19, сообщает, что принятым по умолчанию целевым объектом для конкретного архивного рабочего пространства является главный поток разработки, но в данное время текущим целевым объектом поставки выбран функциональный поток 2.

Эта позиция отражена на структурной диаграмме, показанной на рис. 20. Текущий целевой объект показан сплошной линией, а принятый по умолчанию целевой объект изображен штриховой линией.

Рис. 20. Вид структурной диаграммы после задания нового текущего целевого объекта

Вид "До изменения" также содержит полезную информацию, касающуюся целевых объектов. Любые не принятые по умолчанию целевые объекты изображаются курсивом в верхней строке выводимой информации Pending Changes, как показано на рис. 21.

Рис. 21. Вид PendingChanges: выбран не принятый по умолчанию целевой объект

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

Рис. 22. Предупреждение о передаче информации в не принятый по умолчанию целевой объект

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

Смена целевого объекта в режиме просмотра Pending Changes

Также имеется возможность изменить целевой объект в режиме просмотра Pending Changes. Новый целевой поток можно выбрать, если щелкнуть правой кнопкой мыши на имени архивного рабочего пространства и затем выбрать опцию Change Flow Target.

Роль интегратора

Как было сказано выше, стрелки, соединяющие потоки на структурных диаграммах, показанных на рис. 13, 14, 15 и 20, служат исключительно для указания о намерении передачи работы из одного потока в другой. Человек, которому назначена роль "интегратора", выполняет работу по передаче конкретных изменений из потока в поток. Этот процесс описывается в следующем разделе. Как показано на рис. 4, изменения будут передаваться из потока в поток в следующем порядке (например):

Функциональный поток 1 > главный поток разработки > интеграционный поток > поток выпуска

На практике, массивы изменений должны перетекать из потока в поток через архивное рабочее пространство. Роль интегратора часто сводится к осуществлению этого процесса. Для осуществления передачи массивов изменений из потока в поток необходимо пошаговое выполнение следующих операций:

1. Текущим целевым объектом архивного рабочего пространства назначить исходный поток.
2. Принять все входящие изменения из исходного потока в архивное рабочее пространство.
3. Изменить целевой объект архивного рабочего пространства на целевой поток.
4. Передать исходящие изменения.

Советы:
Весьма целесообразно выполнять эти шаги на чистом интеграционном рабочем пространстве. В противном случае, операция доставки на шаге 4 может захватить локальные изменения, сделанные разработчиком, выполняющим операцию интеграции, а не просто массив изменений, собранных на исходном потоке. Кроме того, перед выполнением операции принятия на шаге 2 следует убедиться в отсутствии исходящих изменений, выводимых в режиме просмотра архивного рабочего пространства Pending Changes.

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

Сбор изменений из функционального потока 1

Установите функциональный поток 1 текущим целевым объектом архивного рабочего пространства (рабочее пространство Марка), как показано на рис. 23. После этого вид Pending Changes для архивного рабочего пространства отобразит входящие изменения, внесенные пользователем Адрианом в функциональный поток 1, как показано на рис. 24. Эти изменения интегратор (Марк) должен включить в рабочее пространство.

Рис. 23. Архивное рабочее пространство, подключенное к функциональному потоку 1

Рис. 24. Принимаемые изменения из функционального потока 1

Доставка изменений в главный поток разработки

Установите главный поток разработки текущим целевым объектом архивного рабочего пространства, как показано на рис. 25. В этом случае вид Pending Changes архивного рабочего пространства покажет исходящие изменения для работы, находящейся в данный момент в архивном рабочем пространстве, как показано на рис. 26. Эти изменения интегратор Марк должен передать из рабочего пространства.

Рис. 25. Архивное рабочее пространство, подключенное к главному потоку разработки

Рис. 26. Доставка изменений в главный поток разработки

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

Контролирование передачи информации в потоки

Можно использовать эту область конфигурирования процессов в проекте для определения тех ролей участников проекта, которым разрешено поставлять изменения в конкретные потоки для конкретного компонента. Соответствующую область конфигурирования можно найти, выполнив следующие шаги в Eclipse-интерфейсе среды Rational Team Concert:

1. Выберите опцию Project Area.
2. Выберите закладку Process Configuration.
3. Выберите опции Team Configuration > Operational Behavior
4. Выберите опцию Source control (Deliver Server).
5. Выберите заголовок столбца Everyone (default)
6. Отметьте флажок "Preconditions and follow up actions are configured for this operation. (Для этой операции предварительные условия и последующие действия сконфигурированы) "
7. Выберите опцию Add и предварительное условие "Restrict Change set delivery to components in a particular stream (Ограничить поставку массива изменений в компоненты в конкретном потоке)"

На рис. 27 показан результат этих действий.

Совет:
По желанию, можно использовать веб-интерфейс вместо Eclipse-интерфейса.

Рис. 27. Конфигурация процесса управления поставками

Увеличенное изображение рис. 27

Для каждого потока можно управлять ролями, которым разрешено вносить массивы изменений, как показано на рис. 28 (который представляет собой увеличенное изображение нижней части рис. 27).

Рис. 28. Контроль разрешений на внесение изменений на ролевой основе

8. Выбрав конкретный поток, например поток выпуска 1.0, можно затем щелкнуть мышью на опции Editpermissions для выбора ролей, которым разрешено внесение изменений в поток.

На рис. 28 показана новая роль с названием "Release Stream Integrators", и только члены команды, имеющие доступ к этому потоку, могут вносить информацию в поток выпуска.

Резюме

Приложение Rational Team Concert предоставляет групповую среду разработки сложного ПО, обеспечивающую высокую степень взаимодействия разработчиков для выполнения современных программных проектов. Большинству команд разработчиков необходима поддержка многочисленных цепочек разработки и обмена изменениями с другими членами команды, работающими над проектом. Потоковая структура и взаимосвязи с рабочими пространствами пользователей превращают такие процессы не просто в возможный, а в весьма эффективный способ сегментации и распределения работы между отдельными разработчиками, обеспечивающий максимальное повышение эффективности работы всей команды разработчиков ПО.