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

Статья ориентирована на новые термины и концепции

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

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

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

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

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

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

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

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

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

Эволюционный

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

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

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

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

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

Введение в приложение Rational Team Concert

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

Поток

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

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

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

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

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

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

Поставка

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

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

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

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

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

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

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

Функциональные потоки

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

Рис. 2. Простая структура функционального потока

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

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

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

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

Рис. 3. Функциональные потоки с совместно используемым потоком интеграции и выпуска

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

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

Разделение потока интеграции и выпуска

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

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

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

Рис. 4. Отдельные потоки интеграции, выпуска и устранения неисправностей

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

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

Рис. 5. Создание структуры второго потока выпуска

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

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

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

Рис. 6. Дальнейшая деятельность по разработке

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

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

Рис. 7. Активность потоков на протяжении всего времени жизни проекта

Создание структуры потока

Новый проект

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

Рис. 8. Исходная структура потоков и архивов проекта

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

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

Подключение к проекту новых разработчиков

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

Рис. 9. Выбор потока, в который будут вноситься изменения

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

Рис. 10. Несколько пользователей, подключенных к одному потоку

Создание новых потоков

Существует несколько способов создания новых потоков. Одним из простейших является использование структурной диаграммы для получения наглядного изображения  взаимосвязей между потоками и архивными рабочими пространствами.

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

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

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

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

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

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

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

Рис. 11. Детали исходного потока

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

Из диалогового окна для потока можно выполнить следующие функции:

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

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

Рис. 12. Конфигурация потока, показывающая индикативную передачу изменений

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

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

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

Рис. 14. Два функциональных потока и главный поток разработки

Завершение создания нового потока

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

Рис. 15. Потоки разработки, интеграции и выпуска

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

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

Рис. 16. Элементы потоков выпуска и исправления неполадок

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

• Другие продукты IBM Rational
• Обратиться к специалистам компании "Интерфейс" для получения дополнительной информации