|
|
|||||||||||||||||||||||||||||
|
Управление параллельной разработкой с помощью IBM Rational Team Concert. Часть 2Источник: IBM
Подключение пользователей к потокам В сценарии параллельной разработки приложений пользователи должны выполнять две основные задачи, касающиеся управления конфигурацией.
Изменение целевого потока для передачи данных В сценарии, показанном на рис. 2, разработчик внес изменения в функциональный поток 1. Этот массив изменений может содержать несколько файлов и, в соответствии с принципами выполнения проекта в среде Rational Team Concert, он либо имеет описание, либо идентифицируется, как элемент потока операций. Изменение содержания файлов выполняется на локальном жестком диске разработчика, а затем регистрируются в серверном архивном рабочем пространстве, при этом все изменения собираются в массив изменений, как показано на рис. 3. После этого изменения передаются в конкретный поток. В сценарии, показанном на рис. 15, пользователи Марк и Симон поставляют свои изменения в главный поток разработки, но Адриан передает свои изменения в функциональный поток 1. Целевой поток для операции поставки является одной из характеристик архивного рабочего пространства разработчика, как показано на рис. 17 для пользователя Марк. Рис. 17. Свойства архивного рабочего пространства Информационный раздел архивного рабочего пространства показывает несколько пунктов с полезной информацией. В соответствии с текущей решаемой задачей он содержит целевой объект для архива, который указывает, в какой поток будут посланы массивы изменений. Для того чтобы изменить целевой объект, выберите опцию Add (в разделе целевого объекта на экране) и затем выберите требуемый поток. Если пользователь с именем Марк хочет передать массивы изменений в функциональный поток 2, а не в главный поток, раздел целевых объектов будет выглядеть так, как показано на рис. 18. Рис. 18. Добавленный альтернативный целевой объект (но не выбранный) Рис. 19. Добавленный альтернативный целевой объект (и установленный как текущий) Позиция, изображенная на рис. 19, сообщает, что принятым по умолчанию целевым объектом для конкретного архивного рабочего пространства является главный поток разработки, но в данное время текущим целевым объектом поставки выбран функциональный поток 2. Рис. 20. Вид структурной диаграммы после задания нового текущего целевого объекта Вид "До изменения" также содержит полезную информацию, касающуюся целевых объектов. Любые не принятые по умолчанию целевые объекты изображаются курсивом в верхней строке выводимой информации Pending Changes, как показано на рис. 21. Рис. 21. Вид PendingChanges: выбран не принятый по умолчанию целевой объект Рис. 22. Предупреждение о передаче информации в не принятый по умолчанию целевой объект Смена целевого объекта в режиме просмотра Pending Changes Также имеется возможность изменить целевой объект в режиме просмотра Pending Changes. Новый целевой поток можно выбрать, если щелкнуть правой кнопкой мыши на имени архивного рабочего пространства и затем выбрать опцию Change Flow Target. Роль интегратора Как было сказано выше, стрелки, соединяющие потоки на структурных диаграммах, показанных на рис. 13, 14, 15 и 20, служат исключительно для указания о намерении передачи работы из одного потока в другой. Человек, которому назначена роль "интегратора", выполняет работу по передаче конкретных изменений из потока в поток. Этот процесс описывается в следующем разделе. Как показано на рис. 4, изменения будут передаваться из потока в поток в следующем порядке (например):
На практике, массивы изменений должны перетекать из потока в поток через архивное рабочее пространство. Роль интегратора часто сводится к осуществлению этого процесса. Для осуществления передачи массивов изменений из потока в поток необходимо пошаговое выполнение следующих операций:
Советы: Сбор изменений из функционального потока 1 Установите функциональный поток 1 текущим целевым объектом архивного рабочего пространства (рабочее пространство Марка), как показано на рис. 23. После этого вид Pending Changes для архивного рабочего пространства отобразит входящие изменения, внесенные пользователем Адрианом в функциональный поток 1, как показано на рис. 24. Эти изменения интегратор (Марк) должен включить в рабочее пространство.
Рис. 24. Принимаемые изменения из функционального потока 1 Доставка изменений в главный поток разработки Установите главный поток разработки текущим целевым объектом архивного рабочего пространства, как показано на рис. 25. В этом случае вид Pending Changes архивного рабочего пространства покажет исходящие изменения для работы, находящейся в данный момент в архивном рабочем пространстве, как показано на рис. 26. Эти изменения интегратор Марк должен передать из рабочего пространства. Рис. 25. Архивное рабочее пространство, подключенное к главному потоку разработки Рис. 26. Доставка изменений в главный поток разработки Таким образом, можно использовать описанный процесс для сбора изменений из любого потока и последующей их передачи в любой другой поток. Однако необходимо обеспечить контроль пользователей, которым разрешена передача изменений в конкретные потоки (например, в поток выпуска). В следующем разделе описана процедура контроля доступа к потокам. Контролирование передачи информации в потоки Можно использовать эту область конфигурирования процессов в проекте для определения тех ролей участников проекта, которым разрешено поставлять изменения в конкретные потоки для конкретного компонента. Соответствующую область конфигурирования можно найти, выполнив следующие шаги в Eclipse-интерфейсе среды Rational Team Concert:
На рис. 27 показан результат этих действий. Совет: Рис. 27. Конфигурация процесса управления поставками Увеличенное изображение рис. 27 Рис. 28. Контроль разрешений на внесение изменений на ролевой основе
На рис. 28 показана новая роль с названием "Release Stream Integrators", и только члены команды, имеющие доступ к этому потоку, могут вносить информацию в поток выпуска. Резюме Приложение Rational Team Concert предоставляет групповую среду разработки сложного ПО, обеспечивающую высокую степень взаимодействия разработчиков для выполнения современных программных проектов. Большинству команд разработчиков необходима поддержка многочисленных цепочек разработки и обмена изменениями с другими членами команды, работающими над проектом. Потоковая структура и взаимосвязи с рабочими пространствами пользователей превращают такие процессы не просто в возможный, а в весьма эффективный способ сегментации и распределения работы между отдельными разработчиками, обеспечивающий максимальное повышение эффективности работы всей команды разработчиков ПО. Ссылки по теме
|
|