IBM Rational Team Concert

Ориентация на понятия и концепции

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

В IBM Rational Team Concert параллельная разработка реализуется путем использования нескольких потоков. Готовая часть работы попадает в определенный поток и интегрируется с работой других разработчиков, работающих с тем же потоком. При использовании нескольких потоков деятельность различных групп разработчиков разделена до тех пор, пока не будет выполнена конкретная задача, после чего наработки из разных потоков интегрируются.

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

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

Является ли такая разработка гибкой?

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

Вследствие физического рассредоточения групп или очевидной сложности проекта может оказаться целесообразным введение в группу гибкой разработки определенной степени разделения и регулируемой интеграции. Эта степень сама может проявляться в потоке для конкретного местоположения или для конкретной версии. Rational Team Concert помогает группам гибкой разработки выполнять разделение работы, например, на серию функциональных потоков, которые объединяются в одно целое посредством совместно используемого интеграционного потока.

Облачные сервисы для бизнеса: особенности рынка и крупнейшие поставщики. Обзор TAdviser 7.4 т

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

Методику Rational Team Concert могут использовать как небольшие единые группы гибкой разработки, так и крупные территориально распределенные группы, состоящие из множества более мелких групп гибкой разработки. Некоторые ключевые характеристики групп гибкой разработки и принципы своевременной поставки при гибкой разработке (Disciplined Agile Delivery) описаны Скотом Эмблером (Scott Ambler) в его блоге (см. раздел Ресурсы).

Эволюционность

По словам Эмблера, гибкие стратегии по своей природе являются итерационными и инкрементными. Потоковой структуре нужно дать эволюционировать с целью поддержки текущих потребностей проекта. При наличии команды, умеющей работать с потоками, процессы интеграции и построения ПО обеспечат поддержку ее деятельности в любой момент времени посредством инструментария управления конфигурацией ПО. Структура параллельной разработки проекта не обязательно должна быть полностью проработана до начала написания кода, но некоторые принципы должны быть понятны всем участникам. К ним относятся управление кросс-потоковой интеграцией, управление потоками выпусков и безопасностью, а также управление работой, которая не завершена в короткие сроки и остается "незаконченной" в потоке или рабочем пространстве.
</DD>

Высокая степень взаимодействия

Механизмы, используемые для совместной работы и поддержания хорошей обозримости деятельности разработчиков, могут превратить среднюю группу гибкой разработки в высокоэффективную. Обучение пользователей механизмам совместного использования контента и сбора информации о деятельности других разработчиков является ключевым моментом в плане недопущения непроизводительных потерь времени и безрезультатной разработки.
</DD>

Самоорганизация в рамках надлежащей инфраструктуры руководства

Управление конфигурацией - это область, по которой написано множество материалов (в том числе и автором данной статьи), но их редко читают. Наличие инфраструктуры руководства надлежащего уровня является ключом к пониманию разработчиками значения действий в области управления конфигурацией. Задание структуры процесса, позволяющей группам разработчиков понять, что им нужно сделать для выпуска готового продукта, и при этом сохранение свободы в том, как это сделать, открывает отличные возможности для творчества и самоорганизации. Такие самоорганизующиеся группы будут стремиться использовать наиболее приемлемый для них подход с учетом характера разработки, навыков группы и доступной технологии автоматизации (дополнительная информация по шаблонам процессов и инфраструктурам автоматизации приведена по ссылке в разделе Ресурсы).
</DD>

Введение в Rational Team Concert

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

Поток

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

Набор изменений

При управлении версиями в Rational Team Concert необходимо управлять внесенными в файлы изменениями и отслеживать их. Некоторые системы управления версиями осуществляют эти процессы пофайлово, так что контент объединяется от ветви к ветви, файл за файлом. Это часто приводит к ошибкам, возникновению неиспользуемого контента или некорректному объединению файлов, следствием чего может стать испорченная сборка или неполностью завершенная работа. В распоряжении разработчиков имеется естественный механизм группирования изменений файлов в наборы, которые логически формируют завершенный блок работы. Задача группирования выполняется как часть процесса регистрации в Rational Team Concert, в котором происходит создание набора изменений и управление им. Затем в большинстве сценариев набор изменений связывается с элементом работы, таким как задание , дефект или версия. Это делает видимым контекст набора изменений и позволяет членам группы просматривать изменения, выполненные для удовлетворения требований данного элемента работы.
</DD>

Базовая линия

В процессе проекта разработки необходимо периодически проводить метафорическую линию на песке и идентифицировать файловое содержимое, которое образует стабильный, пригодный для выпуска элемент программного продукта (или другую единицу полезной работы в рамках системы управления версиями). Такой точкой идентификации в Rational Team Concert является базовая линия. В момент применения базовой линии идентифицируются имеющиеся файлы и их содержимое для конкретной версии. Позже базовые линии могут использоваться в качестве ориентира для получения доступа к конкретной конфигурации файлов. Базовые линии можно сравнивать для демонстрации существующих различий и, таким образом, деятельности разработчиков между двумя зафиксированными моментами времени.</DD>

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

</DD>

Поставка

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

Рабочее пространство пользователя

Каждый пользователь имеет рабочее пространство репозитория, связываемое с потоком, в который он будет передавать свою работу. Когда пользователь выполняет изменение в файле, отредактированная копия сохраняется на стороне клиента в песочнице, связанной с рабочим пространством репозитория. Когда пользователь заканчивает вносить изменения, файл сдается в систему и копируется из клиентской в серверную область репозитория. Файл передается в набор изменений вместе с другими файлами, которые также были изменены пользователем. После завершения формирования набора изменений пользователь передает его в поток.
</DD>

Потоки параллельной разработки

Даже когда пользователи работают в одном потоке (например, функциональный поток 1 на рисунке 1), существует некоторое разделение между пользователями и управляемой интеграцией изменений в процессе поставки и принятия (см. рисунок 3).

Рисунок 1. Регистрация и поставка в потоке

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

<A name=fig2 target=_blank>Рисунок 2. Простая структура функционального потока</A>

На рисунке 2 показан основной поток разработки, в который разработчики передали несколько наборов изменений. На схеме видно, что, например, один набор изменений был передан в поток до поставки #1, а другой - между поставками #1 и #2. Если в рамках проекта никакие другие потоки больше не создаются, то все наборы изменений, поставленные группой, интегрируются в единый совместно используемый поток. Однако работающая над этим проектом группа решила, что несколько разработчиков должны выполнить некие изменения отдельно от остальной группы. Через некоторое время после начала работы над проектом был создан функциональный поток 1. Затем спустя некоторое был создан функциональный поток 2.

Часть работы при этом выполняется в основном потоке разработки, а другая часть - в функциональных потоках. Для простоты на схемах показана только небольшая часть наборов изменений, но в реальности в каждый из потоков по мере выполнения множеством разработчиков их работы поставляется, вероятно, множество наборов изменений. После завершения работы с функциональным потоком 1 группа решает, что этот поток следует интегрировать с основным потоком разработки в точке #2. Специфический процесс интеграции работы из одного потока в другой описан ниже. В точке поставки создается функциональный поток 2, и работа продолжается в трех отдельных параллельных потоках. По достижении точек #3 и #4 работа, выполненная в двух функциональных потоках, вливается в основной поток разработки, и в точке #5 создается базовая линия для выпуска. После окончания поставок из функциональных потоков эти потоки удаляются.

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

Создав в предыдущем разделе сценарий, показанный на рисунке 2, добавим в него дополнительный поток интеграции и выпуска. На рисунке 3 показан новый сценарий, который описывается ниже.

<A name=fig3 target=_blank>Рисунок 3. Функциональные потоки с совместно используемым потоком интеграции и выпуска</A>

Сценарий создания набора изменений, базовой линии и интеграции работы из одного потока в другой соответствует схеме, описанной в разделе Функциональные потоки, но с небольшими изменениями. Поток интеграции и выпуска будет использоваться для формальной интеграции и системного тестирования приложения до его выпуска.

1. В точке #3 в основном потоке разработки, который поставляется в поток интеграции в точке #4, показана базовая линия.
2. Интегрированное приложение может быть протестировано перед выпуском с базовой линии #5 в потоке интеграции и выпуска.
3. После этого продолжается работа по разработке приложения в функциональных потоках до точек #6 и #7, которые затем поставляются в основной поток разработки в точке #8.
4. Затем функциональный поток 2 закрывается и удаляется.
5. Дальнейшая работа продолжается в основном потоке разработки до точки #9, в которой создается новая базовая линия, поставляемая в поток интеграции и выпуска.
6. Затем в совместно используемом потоке интеграции и выпуска в точке #10 создается новая базовая линия для управления выпуском продукта.

<A name=N10170 target=_blank>Разделение потока интеграции и выпуска</A>

Со временем группы разработчиков нередко приходят к заключению о целесообразности разделения потока интеграции и выпуска на отдельные элементы. Это может происходить по следующим причинам:

• Вынос потока выпуска за рамки разработки приложения позволяет группе повысить безопасность этого потока путем управления поставками в него (см. раздел Управление поставками в потоки, посвященный безопасности).
• Необходимые для осуществления интеграции модификации кода можно выполнять в потоке интеграции без нарушения целостности отдельного потока выпуска.
• Изменения, необходимые для оперативной поддержки системы, можно изолировать от основной разработки, что позволит осуществлять их (обычно в конфигурационных файлах), не влияя на основную разработку. Однако должен быть предусмотрен канал для фиксации таких изменений и передачи их обратно в основной поток разработки. Если поток выпуска не изолирован, то такие изменения придется вносить в частично интегрированный код, еще не завершенный и не подготовленный к выпуску. Это может затруднить выпуск продукта или задержать неотложные исправления, необходимые для работы системы.

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

<A name=N1018E target=_blank>Рисунок 4. Отдельные потоки интеграции, выпуска и неотложных исправлений</A>

Код прикладной программы на момент, определенный базовой линией #5, выбран для выпуска, поэтому создается новая иерархия потока выпуска для управления выпуском и возможной работой по неотложным исправлениям, как описано ниже.

1. В точке #6 создается новая базовая линия для выпуска, и с этого момента создается поток неотложных исправлений (который в действительности может и не использоваться).
2. В точке #7 выполняется неотложное изменение, которое поставляется в поток выпуска в точке #8. В большинстве организаций существуют строгие правила относительно вида и объема изменений, которые разрешено выполнять в рамках "неотложных исправлений". Многие организации, разрешающие неотложные исправления, испытывают трудности в передаче этих изменений обратно группе разработчиков.
3. В точке #11 осуществляется передача кода из потока неотложных исправлений в основной поток разработки, чтобы гарантировать внесение данного изменения в следующий формальный выпуск приложения. Также может возникнуть необходимость передачи контента неотложных исправлений из основного потока разработки в функциональный поток 1 или функциональный поток 2 (или в оба), однако на схеме такая ситуация не отражена.
4. В процессе выпуска работа, выполненная в функциональных потоках, поставляется в основной поток разработки в точках #9 и #10.
5. Выполнение работы продолжается в основном потоке разработки вплоть до промежуточной базовой линии #12, которая затем поставляется в поток интеграции, где в точке #13 создается базовая линия для следующего выпуска.
6. Создание потока выпуска и потока неотложных исправлений для управления этим выпуском показано на рисунке 5.

<A name=N101B6 target=_blank>Рисунок 5. Создание структуры второго потока выпуска</A>

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

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

Последняя в разделе схема взаимодействия потоков показывает, как потоки сменяют друг друга в ходе разработки. На рисунке 6 показано, что процесс разработки продолжается, функциональные потоки 1 и 2 завершены, вся выполненная работа доставлена, а потоки удалены. Для продолжения разработки создан функциональный поток 3. Выпуск, связанный с базовой линией #8, также завершен, и, несмотря на то, что поток выпуска сохраняется, поток исправлений можно безопасно удалить.

<A name=N101CE target=_blank>Рисунок 6. Дальнейшая разработка</A>

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

<A name=N101E4 target=_blank>Рисунок 7. Активность потоков на протяжении времени жизни проекта</A>

<A name="3.Creating the stream structure/outline" target=_blank>Создание структуры потока</A>

<A name=N101F7 target=_blank>Новый проект</A>

Когда в Rational Team Concert создается новый проект, он имеет один поток, содержащий компонент по умолчанию. Дополнительные компоненты могут создаваться по мере необходимости, но в контексте данного документа будет использоваться один компонент. На рисунке 8 показаны поток и структура репозитория для нового проекта, в котором предусмотрено рабочее пространство репозитория только для одного разработчика.

<A name=N10202 target=_blank>Рисунок 8. Исходная структура потоков и репозитория проекта</A>

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

Для передачи требуемого потока изменений группы разработчиков должны использовать документацию, например, схемы, изображенные на рисунках 2-6. Это поможет отдельным разработчикам определить, в каком месте потока нужно вносить изменения и кто отвечает за поставку работы в конкретные потоки. Такая документация должна обновляться достаточно часто, чтобы каждый член группы хорошо понимал свои обязанности по мере развития структуры потоков.

<A name=N10217 target=_blank>Подключение к проекту новых разработчиков</A>

Вновь подключенные к проекту пользователи могут получить доступ к файлам для внесения изменений путем создания нового рабочего пространства репозитория. Эта операция выполняется в несколько шагов: вначале выберите пункт My Repository Workspaces (см рисунок 8), затем New, а затем Repository Workspace. При этом отобразится диалоговое окно, показанное на рисунке 9, где можно выбрать поток, в который будут поставляться изменения ("втекать"). Общее количество потоков проекта обычно невелико, поэтому нужный поток выбрать просто, если потокам присвоены подходящие описательные имена.

<A name=N1022B target=_blank>Рисунок 9. Выбор потока, в который будут вноситься изменения</A>

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

<A name=N1023D target=_blank>Рисунок 10. Несколько пользователей, подключенных к одному потоку</A>

<A name="4.Creating new streams/outline" target=_blank>Создание новых потоков</A>

Пояснение по передаче информации из потока в поток

Однако создание индикативных связей между потоками дает наглядную картину того, что изменения, накопленные в одном потоке, в конечном счете будут переданы в другой поток в рамках процесса разработки. Для создания индикативных связей между потоками необходимо открыть окно параметров исходного потока, как показано на рисунке 11. <P>Существует несколько способов создания новых потоков. Одним из простейших является использование блок-схемы, предоставляющей наглядное изображение взаимосвязей между потоками и рабочими пространствами репозитория.

При щелчке правой кнопкой мыши на потоке отображается меню с различными функциями и опциями.

• Создать новое рабочее пространство репозитория.
• Создать новый поток.
• Обновить схему с использованием информации из базы данных репозитория.
• Сравнить состояние потока с текущим состоянием любого из следующих объектов:
  • Другого потока.
  • Конкретного рабочего пространства.
  • Конкретного снимка состояния потока.

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

В сценарии на рисунке 2 первый создаваемый поток называется Feature Stream 1. Сразу после создания поток имеет то же содержимое, что и поток, из которого он был создан. Кроме того, новый поток не имеет никаких взаимосвязей с другими потоками и связанных с ним рабочих пространств.

<A name=N10284 target=_blank>Рисунок 11. Параметры исходного потока</A>

<A href="http://www.ibm.com/developerworks/ru/library/r-parallel-development-rational-team-concert/fig11_lg.html" target=_blank>Увеличенная версия рисунка 11</A>.

В диалоговом окне для потока можно выполнять следующие действия:

• Создавать новые компоненты.
• Добавлять или обновлять ссылки из других проектов (с определенных базовых линий).
• Добавлять и удалять целевые объекты передачи.

К функциональному потоку 1 добавляется новый целевой объект передачи изменений в основной поток разработки. Такая конфигурация потока показана на рисунке 12.

<A name=N102AC target=_blank>Рисунок 12. Конфигурация потока с индикативной передачей изменений</A>

На рисунке 13 показана обновленная блок-схема, на которой изображены три разработчика, работающие в данный момент с основным потоком разработки.

<A name=N102BE target=_blank>Рисунок 13. Блок-схема с потоками и рабочими пространствами репозиториев</A>

Добавление функционального потока 2 (см. рисунок 14) завершает сценарий, показанный на рисунке 2.

<A name=N102D0 target=_blank>Рисунок 14. Два функциональных потока и основной поток разработки</A>

<A name=N102DD target=_blank>Завершение создания нового потока</A>

Для завершения показанной на рисунке 4 структуры потоков, которая состоит из потоков интеграции, выпуска и оперативных исправлений, создаются новые потоки и устанавливаются связи целевых объектов передачи с использованием описанного выше механизма. Результаты показаны на рисунке 15.

<A name=N102E8 target=_blank>Рисунок 15. Потоки разработки, интеграции и выпуска</A>

В левой части рисунка 15 показана связанная с разработкой проекта деятельность группы, в которой два разработчика (Марк и Саймон) работают с основным потоком разработки, а Адриан работает с функциональным потоком 1 (прежде Адриан работал с основным потоком разработки, а сейчас он работает над конкретными функциями в отдельном потоке). Марк и Саймон интегрируют свою работу путем поставки наборов изменений в основной поток разработки и последующего приема наборов изменений из этого потока. Схема упрощена в части количества пользователей, работающих с каждым потоком. Предполагается, что Адриан и другие разработчики будут совместно работать с функциональным потоком 1, а другие разработчики будут совместно использовать функциональный поток 2.

Справа от основного потока разработки показана структура потоков для поддержки процесс выпуска и исправлений. Поток интеграции используется для постепенной (и управляемой) интеграции вносимых изменений. После создания соответствующей базовой линии в потоке интеграции его текущее состояние (наборы изменений и базовые линии) поставляется в поток выпуска 1.0. Поток выпуска для конкретной версии создается, как схематически показано на рисунке 4, а также на блок-схеме на рисунке 15. Он позволяет поддерживать несколько потоков выпуска для реализации сценария, предусматривающего одновременное использование нескольких выпусков. Такие выпуски могут потребовать применения к ним неотложных исправлений. В примере на рисунке 16 первый выпуск при создании имеет набор изменений с базовой линии #8. Возможна ситуация, когда у заказчиков, использующих данный выпуск приложения, возникнет потребность в дополнительных неотложных исправлениях ошибок после прохождения базовой линии #8 при отсутствии возможности приобрести самый последний выпуск приложения, показанный на втором потоке выпуска. Таким образом, поддержка возможности внесения исправлений в выпуск, созданный с базовой линии #6, имеет большое значение.

<A name=N10300 target=_blank>Рисунок 16. Элементы потоков выпуска и неотложных исправлений</A>

Поток неотложных исправлений, обозначенный на рисунке 15 как "Release Stream 1.0 - E-Fix", предназначен для максимально быстрого внесения неотложных изменений в подготавливаемый к выпуску продукт. Эти изменения не затрагивают исходный код и его перекомпиляцию; во многих случаях они относятся к конфигурационным файлам и настройкам, которые требуют немедленного обновления. Тем не менее эти изменения передаются в отдельный поток, гарантирующий, что потоки выпуска не будут использованы при разработке. Неотложные изменения, вероятно, тоже необходимо вносить в поток разработки, чтобы они естественно перетекали в следующий выпуск. На рисунке 4 показан набор изменений #7, поставляемый в поток выпуска и основной поток разработки в точке #11.

<A name="5.Connecting users to streams/outline" target=_blank>Подключение пользователей к потокам</A>

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

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

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

<A name=N10325 target=_blank>Изменение целевого потока для поставки</A>

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

<A name=N10330 target=_blank>Рисунок 17. Свойства рабочего пространства репозитория</A>

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

<A name=N10345 target=_blank>Рисунок 18. Альтернативный целевой объект добавлен, но не выбран</A>

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

<A name=N10357 target=_blank>Рисунок 19. Альтернативный целевой объект добавлен и установлен как текущий</A>

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

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

<A name=N1036C target=_blank>Рисунок 20. Вид блок-схемы после задания нового текущего целевого объекта</A>

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

<A name=N1037E target=_blank>Рисунок 21. Представление PendingChanges: выбран объект, не являющийся целевым объектом по умолчанию</A>

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

<A name=N10390 target=_blank>Рисунок 22. Предупреждение о поставке в объект, не являющийся целевым объектом по умолчанию</A>

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

<A name=N103A6 target=_blank>Изменение целевого объекта в представлении Pending Changes</A>

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

<A name="6.The Integrator role/outline" target=_blank>Роль интегратора</A>

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

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

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

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

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

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

<A name=N103DE target=_blank>Сбор изменений из функционального потока 1</A>

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

<A name=N103E9 target=_blank>Рисунок 23. Рабочее пространство репозитория, подключенное к функциональному потоку 1</A>

<A name=N103F8 target=_blank>Рисунок 24. Прием изменений из функционального потока 1</A>

<A name=N10405 target=_blank>Поставка изменений в основной поток разработки</A>

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

<A name=N10410 target=_blank>Рисунок 25. Рабочее пространство репозитория, подключенное к основному потоку разработки</A>

<A name=N1041F target=_blank>Рисунок 26. Поставка изменений в основной поток разработки</A>

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

<A name="7.Controlling deliveries to streams/outline" target=_blank>Управление поставками в потоки</A>

В области Process Configuration проекта можно определить роли проекта, которым разрешено поставлять изменения в конкретные потоки для конкретного компонента. Соответствующую область конфигурирования можно найти, выполнив следующие шаги в 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-интерфейса можно использовать Web-интерфейс.

<A name=fig27 target=_blank>Рисунок 27. Конфигурация процесса управления поставками</A>

<A href="http://www.ibm.com/developerworks/ru/library/r-parallel-development-rational-team-concert/fig27_lg.html" target=_blank>Увеличенная версия рисунка 27</A>.

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

<A name=N10487 target=_blank>Рисунок 28. Управление разрешениями на внесение изменений на основе ролей</A>

8. Выбрав конкретный поток (например, поток выпуска 1.0), можно щелкнуть кнопкой мыши на Edit permissions и назначить роли, которым разрешено вносить изменения в поток.

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

<A name=8.Summary/outline target=_blank>Заключение</A>

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