Одним из основных направлений деятельности подразделения разработки систем (Systems Development Branch, SDB) в Исследовательском центре NASA в Лэнгли (Langley Research Center, LaRC) является разработка программного обеспечения (ПО) для исследовательских имитаторов и исследовательских самолетов. SDB вкладывает значительные средства в разработку многократно используемых программных компонентов. Продукты представляют собой комбинацию этих многократно используемых компонентов (которые называются совместно используемым кодом) и кода проекта. Для совместно используемого кода подразделение SDB необходимо использовать полномочия на изменения уровня организации. (Здесь полномочия на изменения позволяют осуществить вступление в силу одобрений на изменения. Т.е. полномочия позволяют сделать видимыми только те изменения, которые одобрены.) Каждый проект нуждается в своих собственных полномочиях на изменения. Однако проекты поддерживают совместно используемый код. Каждому проекту нужна свобода изменения совместно используемого кода в изоляции от других проектов, пока изменения не будут готовы для передачи в совместное использование. При множестве проектов, работающих с совместно используемым кодом, разделение этого кода на несколько базовых линий 1 , каждая из которых обладает собственным сообществом пользователей, представляет собой проблему. Подразделение SDB разработало процессы выпуска версий ПО и внедрения изменений, позволяющие поддерживать единую развивающуюся базовую линию. Проекты SDB работают в совместной компьютерной среде с ограниченным количеством платформ развертывания для тестирования и производственной эксплуатации. Разработчикам необходимо планировать время для тестирования систем. Для максимального повышения эффективности использования отведенного им времени разработчикам требуются короткие циклы обработки сборок. Разработчикам также нужно работать без помех со стороны других проектов.
SDB использует ClearCase для автоматизации управления конфигурациями в этих проектах с высокой степенью повторного использования. В этой статье обсуждается, как SDB применяет ClearCase в четырех ключевых областях.
- Полномочия на изменения. В SDB разработали свою структуру базы данных (БД) версий объектов (Versioned Object Base, VOB), чтобы обеспечить разделение полномочий на изменения и одновременно дать возможность проектам участвовать в поддержке многократно используемых компонентов.
- Выпуск версий ПО. Стратегия "проталкивания" ("Push-Forward") версий ПО гарантирует, что старые версии не станут сами по себе продуктами.
- Внедрение изменений. Правило "Одно представление - один отдел - одна задача" не позволяет проекту создавать свою собственную "песочницу" (безопасную ограниченную среду) вне совместно используемого кода.
- Управление сборками. Clearmake позволяет разработчикам выполнять сборки в обычное рабочее время, не мешая действиям других разработчиков в совместной компьютерной среде. SDB также использует возможности ClearCase для предотвращения конфликтов общих библиотек. Такие конфликты случаются, когда несколько разработчиков на одном компьютере запускают продукты, которые содержат варианты одинаковых динамически загружаемых библиотек.
Рисунок 1. Рабочая среда SDB.
SDB использует для поддержки своего процесса управления конфигурациями только "базовый" продукт ClearCase. SDB не использует унифицированное управление изменениями (Unified Change Management, UCM), и оно не обсуждается в этой статье.
Рабочая среда SDB предоставляет контекст для обсуждения методик использования ClearCase, принятых в SDB. SDB работает в рамках концепции "от имитации к полету". Каждый проект представляет собой эксперимент, который изучает исследовательскую концепцию. Сообщество NASA сообщает подразделению SDB требования к эксперименту. SDB разрабатывает систему (аппаратное и программное обеспечение), которая реализует эксперимент. Этот экспериментальный продукт затем передается в имитатор. Эксперимент проводится в смоделированной среде самолета, где люди (пилоты) оперируют органами управления. Имитатор предоставляет реалистичные визуальные представления "вида из окна". При необходимости его можно состыковать с подвижной платформой, чтобы обеспечить пилотам реалистичные динамические ощущения. В имитаторе эксперимент проходит процесс "созревания". Если эксперимент предназначен для летных испытаний, то он передается в лабораторию системной интеграции. Лаборатория системной интеграции - это копия рабочей среды на исследовательском самолете. В лаборатории проверяются безопасность и функциональность экспериментального продукта. В случае обнаружения проблем экспериментальный продукт можно вернуть в имитатор для дополнительной оценки. После того как экспериментальный продукт прошел тесты функциональности и безопасности в лаборатории, он передается в исследовательский самолет для летных испытаний.
Для этой среды SDB разрабатывает ПО для исследований, ПО для имитации и встроенное ПО. Исследовательское ПО - это ПО в экспериментальном продукте. ПО для имитации обеспечивает физическое моделирование самолета и окружающей среды в имитаторе. Встроенное ПО в основном служит для маршрутизации данных между сетью реального времени и устройствами в кабине. Часть оборудования кабины изготавливается своими средствами, и его внутренняя логика реализуется с помощью встроенного ПО. Законы управления подвижной платформой также реализуются с помощью встроенного ПО, созданного подразделением SDB.
В качестве целевой операционной системы (ОС) для исследовательского и имитационного ПО используется IRIX. Целевая ОС для встроенного ПО - VxWorks. SDB поставляет настольные версии некоторых своих продуктов, чтобы помочь сообществу NASA при формулировании экспериментальных требований и создании своих собственных исследовательских продуктов. Эти настольные версии работают на ОС Solaris, Red Hat Linux и Windows 2000. Вся разработка ПО для имитационных, встроенных и настольных сред управляется с использованием процессов, описанных в данной статье. В настоящее время SDB поддерживает в общей сложности 2 млн. строк программного кода. Этот код разделен на 71 VOB в ClearCase. SDB разрабатывает ПО с использованием объектно-ориентированных методик и в основном пишет код на C++.
В SDB работают 36 разработчиков. В коллективе нет разделения ролей. Например, в подразделении нет группы обеспечения качества (Quality Assurance, QA) 2 . Разработчики выполняют все действия жизненного цикла, от анализа требований до развертывания и эксплуатации. На момент написания этой статьи в SDB было 46 активных проектов на различных этапах жизненного цикла. Очевидно, разработчики не могут разрабатывать такое множество продуктов одновременно. В каждый момент времени в разработке находится лишь около трети активных проектов; основная часть находится в фазах сопровождения или эксплуатации, некоторые находятся в стадии требований.
Совместно используемый код и код проекта
Все продукты представляют собой комбинацию совместно используемого кода и кода проекта. Совместно используемый код предназначен для многократного использования в различных проектах. SDB придает особое значение многократно используемому ПО. В SDB многократно используемые компоненты собраны в инфраструктуры (framework). Например, в SDB создана инфраструктура моделирования, которая называется Langley Standard Real-Time Simulation in C++ (LaSRS++). Все имитационные продукты создаются на базе среды LaSRS++. Поскольку изменения в совместно используемом коде могут повлиять на множество проектов, для этого кода необходим контроль конфигураций на организационном уровне. Код проекта - это код, предназначенный только для одного проекта. Поскольку изменения в коде проекта влияют только на этот проект, управление конфигурациями кода выполняет лидер проекта. Процесс, которому следует лидер проекта, создается на базе организационного плана управления конфигурациями для проектов.
В SDB нет специально выделенной группы для сопровождения совместно используемого кода. Почти все финансирование проектов SDB осуществляется внутренними "заказчиками" NASA. Вся работа должна быть отнесена на счет определенного проекта. Таким образом, проектные группы выполняют сопровождение совместно используемого кода в соответствии со своими нуждами. При этом SDB поддерживает организационный процесс для одобрения изменений в совместно используемом коде, но разрабатывает и реализует эти изменения проектная группа. Каждая версия совместно используемого кода представляет улучшения, которые удовлетворяют требования ряда проектов. Поэтому в каждый определенный момент времени используется несколько версий совместно используемого кода. Подразделение SDB должно поддерживать множество специализированных комбинаций версий кода проекта и совместно используемого кода.
Децентрализованное сопровождение совместно используемого кода оказывает существенное влияние на процесс управления конфигурациями, описанный в данной статье.
Поскольку весь код порождается проектами, некоторая часть кода начинает свою жизнь как код проекта, но позже, когда находит применение в других проектах, переходит в разряд совместно используемого кода. Новые имитационные модели самолетов обычно начинают свою жизнь в рамках кода проекта. При этом модель самолета изначально нужна только для первого проекта. Когда модель уже проверена в одном проекте, другие заказчики могут выбрать ее в качестве платформы для других экспериментов. Эта модель затем становится совместно используемым кодом. Некоторая часть встроенного и исследовательского кода также начинает свою жизнь как код проекта, а затем переходит в разряд совместно используемого кода. Процедуры, реализованные для ClearCase, должны обеспечивать этот переход 3 .
Рисунок 2. Структура VOB в SDB.
Управление через структуру VOB
Как объяснялось в предыдущем разделе, продукты представляют собой комбинацию базовых линий совместно используемого кода и кода проекта. Также все изменения в совместно используемом коде выполняются в рамках конкретных проектов. Однако полномочия на управление конфигурациями различают код проекта и совместно используемый код. Внедрение ClearCase должно поддерживать различные полномочия на изменение и одновременно позволять проектным работам использовать базу данных VOB совместно используемого кода. Механизм для такого "кооперативного управления конфигурациями" предоставляет ClearCase AdminVOB.
SDB использует структуру VOB, изображенную на рис. 2. Пользователь, vobadm, является владельцем БД VOB совместно используемого кода (показанной зеленым). Полномочиями идентификатора vobadm могут обладать только назначенные библиотекари и системные администраторы. Для управления видимостью изменений основная ветвь блокируется для всех пользователей, исключая пользователя vobadm. Таким образом, только библиотекари могут осуществлять слияние изменений в основной ветви. Блокировка не позволяет проектам вносить в основную ветвь неконтролируемые изменения, которые могли бы неблагоприятно повлиять на другие продукты.
Каждый проект получает свою БД VOB, в которой размещается код проекта (показан оранжевым). Владеет БД VOB проекта лидер этого проекта, поскольку у него есть полномочия на внесение изменений в код проекта. Лидер проекта волен решать, когда блокировать основную ветвь VOB проекта перед началом системных тестов. Процесс в SDB требует, чтобы проекты блокировали свою основную ветвь перед тем, как начнется системное тестирование продукта. Лидер проекта также контролирует внесение изменений в основную ветвь. Выполнение слияния не входит в обязанности лидера проекта. Он просто обладает полномочиями на принятие решений и может попросить библиотекарей совместно используемого кода о выполнении слияния.
VOB для кода проекта и совместно используемого кода используют одну и ту же административную базу VOB (AdminVOB). (Ссылка на AdminVOB показана красным.) AdminVOB предоставляет глобальные метки и ветви. Глобальные метки позволяют проектам идентифицировать версии продуктов за счет применения одной метки для обеих частей (кода проекта и совместно используемого кода). Глобальные ветви позволяют проектам реализовывать и определять задачи, в которые вовлечен и код проекта, и совместно используемый код.
SDB требует, чтобы все метки были глобальными. Глобальные метки - это лучший механизм для идентификации версии продукта, поскольку продукты собираются из кода проекта и совместно используемого кода, который размещается в двух или более VOB. Дополнительное преимущество глобальных меток состоит в идентификации версий совместно используемого кода, поскольку инфраструктуры SDB имеют тенденцию к использованию нескольких VOB. Например, среда LaSRS++ использует семь БД VOB. Основным преимуществом глобальных меток перед локальными VOB-метками является автоматизированное копирование. Когда глобальная метка впервые прикрепляется к версии в VOB, ClearCase автоматически создает локальную копию глобальной метки и применяет эту локальную копию к версии. Локальная копия сохраняет ссылку на глобальную метку в AdminVOB, так что локальная копия применяет все управляющие действия, связанные с глобальной меткой. Другими словами, глобальная метка становится единой точкой управления всеми ее копиями. Другим преимуществом использования глобальных меток является то, что AdminVOB становится центральной БД для запросов истории версий продукта.
Аналогично SDB требует, чтобы все ветви были глобальными. Поскольку продукты создаются на базе и кода проекта, и совместно используемого кода, разработчик не всегда может предсказать, потребует ли проектная задача изменений в обоих видах кода. Например, во время интеграционного тестирования нового кода проекта разработчик может обнаружить в совместно используемом коде дефект, который до этого был неизвестен.
Задача тестирования изначально подразумевала модификацию только кода проекта, но обнаружение дефекта вынуждает вносить изменения и в совместно используемый код. Разработчик хочет зафиксировать исправление дефекта в новом коде проекта, поскольку изменения в совместно используемом коде были сделаны в контексте проектной задачи. Разработчику нужна ветвь, которая легко охватывала бы VOB и с проектным, и с совместно используемым кодом. Этим требованиям удовлетворяют глобальные ветви. Аналогично глобальным меткам, ClearCase автоматически создает локальную VOB-копию глобальной ветви, где ветвь впервые применяется к элементу в локальной БД VOB. Эта автоматическая копия работает с правилами автоматического создания ветви (auto-make-branch) в спецификациях конфигурации представления (config specs). Когда в VOB впервые производится сдача работы из представления с правилом автоматического создания ветви, глобальная ветвь автоматически появляется в VOB в перспективе разработчика. Локальная копия сохраняет ссылку на глобальную ветвь, так что локальная копия выполняет все управляющие действия, проделанные с глобальной ветвью. Аналогично глобальные ветви помогают при модификациях, которые затрагивают лишь совместно используемый код, поскольку инфраструктуры могут охватывать несколько VOB. Как уже говорилось ранее, проекты могут переходить в совместно используемый код. Таким образом, желательны ветви, которые могут распознаваться в VOB и для проектного, и для совместно используемого кода. Поскольку и у проектных, и у совместно используемых VOB есть общая БД AdminVOB, они будут признавать все ветви, созданные в этой БД AdminVOB. Общая БД AdminVOB для проектных и совместно используемых VOB позволяет проектам реализовывать изменения и определять версии, которые вливаются в совместно используемые VOB, не привлекая библиотекарей совместно используемых VOB. В то же время проектные и совместно используемые VOB сохраняют свои индивидуальные полномочия на изменения. Назначенные библиотекари контролируют видимость изменений в совместно используемых VOB. Лидеры проектов контролируют проектные VOB.
Стратегия "проталкивания" версий
При сопровождении совместно используемого кода, распределенного среди нескольких проектов, существует опасность появления разных вариантов совместно используемого кода. В SDB создали процедуры ClearCase для обнаружения вариантов. Эти процедуры реализованы в "Стратегии проталкивания версий" ("Push-Forward Release Strategy") и правиле "Одно представление - один отдел - одна задача" ("One View - One Branch - One Task"). "Стратегия проталкивания версий" определяет базовые линии совместно используемого кода и то, как проекты реагируют на новые версии. Это и обсуждается в этом разделе. Правило "Одно представление - один отдел - одна задача" определяет, как проекты реализуют изменения в совместно используемом коде. Это будет обсуждаться в следующем разделе.
Рисунок 3. Базовые линии совместно используемого кода в ClearCase.
Процесс в SDB определяет три базовые линии для совместно используемого кода: разработчика, интеграции и производства. Базовая линия разработчика представляет собой незавершенные ("in-progress") изменения. Она видна только разработчику, который вносит изменения. Базовая линия интеграции создается, когда одна (или несколько) базовых линий разработчика становятся видимыми для всей группы разработчиков. Перед выпуском версии ПО изменения в базовой линии интеграции проходят экспертную оценку и проверку взаимодействия со стороны спонсирующего проекта, но они еще не включены в другие проекты 4 . Базовая линия производства отображает базовую линию интеграции, которая успешно прошла системные и приемочные тесты в рамках проекта.
На рис. 3 показано, как базовые линии представлены в ClearCase. Когда разработчик изменяет совместно используемый код, он должен создать в основной ветви дополнительную ветвь 5 . Работа, которая делается в этой ветви, представляет собой базовую линию разработчика. Когда изменения прошли экспертную оценку и интеграционное тестирование, это изменение сливается с основной ветвью. Эту ветвь разработчика можно одновременно объединить с другими базовыми линиями разработчика. Для простоты на рис. 3 показано только одно слияние. Вновь объединенные изменения формируют новую базовую линию интеграции. Новую базовую линию интеграции идентифицирует определенная метка. Метка, которая используется для базовых линий интеграции и производства, имеет форму framework_major.minor , например LaSRS_3.11. "Framework" - это название инфраструктуры. "Major" - основной номер версии. "Minor" - вспомогательный (дополнительный) номер версии. Базовая линия интеграции обладает меткой с дополнительным номером версии, отличным от нуля. Каждая новая базовая линия интеграции увеличивает дополнительный номер версии. Когда системное и приемочное тестирование базовой линии интеграции проекта завершается, она становится базовой линией производства. Конфигурации назначается вторая метка. Эта метка увеличивает основной номер версии и обнуляет дополнительный номер версии.
Расстановка меток версий полностью основана на событиях, а не на порядке версий. Это показано на рис. 3. Метка базовой линии производства может иметь больший основной номер версии, чем метка интеграции. Однако базовая линия производства может содержать более старый набор версий, чем базовая линия интеграции. Первое время это нарушает "чувство порядка". Однако в SDB задались вопросом: в какой мере это действительно препятствует созданию и сопровождению качественного продукта. Для SDB ответ был "ни в какой". \SDB просто нужен был механизм дифференциации между базовыми линиями интеграции и производства, а схема меток - это просто удобный механизм для создания следующей метки. Дополнительные процессы, которые обеспечивали бы соответствие между порядком меток и порядком версий, просто породили бы дополнительную работу, ничего не дающую для повышения качества продукта или для сокращения времени вывода продуктов на рынок. Эти процессы служили бы лишь для удовлетворения эстетического чувства порядка. В итоге в SDB сохранили процесс расстановки меток в таком виде, как показано на рис. 3.
"Проталкивательная" составляющая стратегии выпуска определяет, как проекты реагируют при создании новой базовой линии интеграции. Эта стратегия показана на рис. 4. Когда проект находится в стадии разработки, он должен непрерывно развиваться, успевая за последней интеграционной версией. Если проект изменяет совместно используемый код, эти изменения оказываются в ветви, которая отличается от основной. Чтобы не отставать от последней базовой линии интеграции, проект должен выполнять слияние при каждом создании базовой линии интеграции. Это гарантирует, что в проекте будут учтены самые последние изменения в основной ветви, если проект и базовая линия интеграции имеют общие измененные файлы. Когда проект завершил изменения в совместно используемом коде, их нужно передать во все остальные ветви для слияния. Это делается до возможного начала тестирования продукта (т.е. до системных и приемочных испытаний). После этого разработчики могут заморозить свое представление в соответствии со вновь созданной базовой линией интеграции. Эта базовая линия становится кандидатом на базовую линию производства. Проект может игнорировать последующие создаваемые базовые линии интеграции. Если проект возвращается в состояние разработки, то он опять должен работать с последней ветвью интеграции. Проект возвращается в состояние разработки, когда в его рамках нужно изменить совместно используемый код для исправления дефекта, обнаруженного при тестировании продукта. Также это делается, когда вносятся дополнительные улучшения в совместно используемый код в фазе сопровождения. Таким образом, проекты "проталкиваются" для использования самой последней версии. Проект не остается "забытым" на стадии работы с версией интеграции, с которой он начинался. Проект не оказывается в ситуации, когда приходится создавать вариант совместно используемого кода из-за того, что у разработчиков нет времени на оценку огромного количества изменений, добавленных в основную ветвь с момента начала проекта. Стратегия "проталкивания" также поддерживает реальное совместное использование кода. От проектов требуется "поглотить" и оценить изменения в других проектах. Это дает всем стимул участвовать в оценке дизайна и изменений в коде, что увеличивает вероятность разработки и реализации изменений для использования в других проектах.
Для успеха стратегии "проталкивания" важно участие сообщества в экспертных оценках. Это сокращает число изменений в коде, которые становятся сюрпризом для других разработчиков. Таким образом, согласование слияний, которые возникают в результате стратегии "проталкивания", обычно занимает немного времени. Время согласования также сильно зависит от масштаба изменений, вносимых новой базовой линией интеграции. Как будет сказано в следующем разделе, базовые линии интеграции создаются не чаще раза в неделю. Это обеспечивает баланс между нарушениями работы из-за частоты изменений и нарушениями из-за объема изменений. Раз в неделю - это достаточно редко, чтобы разработчики не тратили основную часть времени на согласование новых версий интеграции, но достаточно часто, чтобы между версиями интеграции не нарастали большие объемы изменений. На время согласования также влияет зрелость совместно используемого компонента. Новые компоненты и компоненты, подвергающиеся серьезным обновлениям, обычно накапливают изменения с большей скоростью, чем зрелые продукты, подвергаемые незначительным улучшениям. В SDB большинство наших совместно используемых компонентов являются зрелыми. Поэтому согласование большинства "проталкиваемых" слияний занимает менее часа. Однако отдельные разработчики все же иногда сталкиваются с версиями, согласование которых занимает несколько дней. Это исключение, а не правило. Даже во время последнего большого обновления наших совместно используемых компонентов три года назад время согласования, превышающее час, встречалось хотя и чаще обычного, но все же не было правилом.
Рисунок 4. Стратегия "проталкивания" версий.
Экспертные оценки также способствуют хорошему дизайну. Стратегия "проталкивания" не будет работать с плохо спроектированной системой. Для подобных систем характерны необъяснимые сбои при внедрении, казалось бы, посторонних изменений. Разработчики вынуждены прибегать к хакерским методам, чтобы исправить проблемы, поскольку лежащие в их основе пороки имеют слишком глубокие корни. Поэтому такие ошибки невозможно устранить в короткие сроки. В такой среде разработчики будут ощущать, что любая версия интеграции может с высокой вероятностью нарушить работу их текущего продукта. Разработчики не будут привязываться к процессу, поскольку это принесет им больше вреда, чем пользы.
Правило "Одно представление - один отдел - одна задача"
Стратегия "проталкивания" версий борется с дроблением совместно используемого кода, требуя от сообщества принятия изменений. Однако она не предотвращает чрезмерного накопления изменений в проектах. Проект, который не предоставляет свои изменения в совместное использование, должен сохранять их в отдельной ветви, которая продолжает расти вместе с проектом. Подобные долгоживущие ветви имеют тенденцию к накоплению большого количества элементов, а история изменений каждого отдельного элемента становится все сложнее. Со временем слияние с другой ветвью становится все более затруднительным. Также существует повышенный риск возникновения нежелательных побочных эффектов из-за слияний, например, исчезновения исправлений ошибок из основной ветви после объединения с долго существовавшей отдельно ветвью. Особенно большую проблему представляют долгоживущие ветви в совместно используемом коде. Изменения, внесенные в совместно используемый код, уже одобрены как полезные для текущего или будущих проектов.
Поэтому другой проект в конечном итоге потребует этих изменений. Если эти изменения еще не существуют в основной ветви, то проект будет должен включить долгоживущую ветвь в свои представления. Подобные долгоживущие ветви начинают собирать свое собственное сообщество пользователей. Организация может обнаружить, что один ряд проектов использует основную ветвь, а остальные используют долгоживущую ветвь. В результате база совместно используемого кода разделяется, и потом требуется значительная работа по согласованию двух конфигураций.
Из-за совместного использования ветви могут возникать и другие проблемы. Другим проектам может потребоваться изменить совместно используемую ветвь и создать на ее основе новую ветвь, которая будет содержать модификации. Эти подветви нельзя объединить с основной ветвью, пока не будет проведено слияние для совместно используемой ветви. Например, проект FIRST размещает все свои изменения в ветви, которая называется everything_but. Проект NEXT включает в себя ветвь everything_but, чтобы получить одну из модификаций в этой ветви. Проект NEXT делает свои собственные модификации в изменениях проекта FIRST в ветви под названием kitchen_sink. Таким образом, набор изменений проекта NEXT распространяется на ветви everything_but и kitchen_sink. Затем проект NEXT становится готовым к переходу к тестированию продукта.
Однако проект FIRST продолжает добавлять изменения в everything_but, и он не готов к слиянию everything_but и основной ветви. Поскольку тестирование продукта нужно выполнять на версиях из основной ветви, проект NEXT ставится на ожидание, пока проект FIRST завершит свои изменения. После этого проект NEXT может перейти к тестированию своего продукта. По мере вовлечения все большего числа проектов эта ситуация может перерасти в целую паутину зависимостей ветвей. Эта паутина зависимостей может легко привести к длительным и запутанным спецификациям конфигураций для представлений проектов. Если проект, который владеет совместно используемой ветвью, не защищает ее должным образом, другие проекты могут случайно добавить в нее изменения. При сложных спецификациях конфигураций подобные изменения могут легко распространиться на ветви, где часть изменений существует в совместно используемой ветви, а другая часть существует в другой ветви. Эти две ветви теперь тесно связаны. Ни одна из них не является полной без другой. Такую ситуацию можно разрешить лишь слиянием одной ветви и другой.
Чтобы сократить число долгоживущих ветвей, в SDB создали правило "Одно представление - один отдел - одна задача" ("One View - One Branch - One Task"). Это правило гласит, что разработчик создает ветвь для каждой задачи, и что представление от начала и до конца этой задачи будет работать только с одной ветвью. Задача - это наименьший связный набор действий, который может определять разработчик. Предпочтительно задача должна представлять собой работу длительностью примерно две недели. Задача не должна подразумевать работу длительностью больше трех месяцев.
Разработчик создает ветвь, чтобы хранить изменения для простой задачи. После выполнения задачи разработчик передает ветвь библиотекарю, чтобы слить ее с основной ветвью. После слияния ветвь блокируется с опцией "-obsolete". Для своей следующей задачи разработчик должен создать новую ветвь. При работе с ветвью разработчик должен выделить для нее представление. В спецификации конфигурации этого представления не должны появляться никакие другие ветви, пока ветвь находится в разработке. Если разработчик одновременно работает над несколькими задачами, то он должен создать представление для каждой ветви. Разработчикам рекомендуется удалять представления, когда соответствующие ветви больше не нужны. Благодаря этому представления остаются небольшими и высокопроизводительными. Это позволяет быстрее вычистить устаревшие совместно используемые производные объекты из VOB, поскольку VOB будет хранить совместно используемый производный объект до тех пор, пока на него ссылается хотя бы одно представление. Долгоживущее представление может сохранять ссылки на множество устаревших производных объектов, которые занимают дисковое пространство. Рекомендация удалять представления после прекращения использования ветвей также подчеркивает, что личные элементы представлений являются временными. Файл, обладающий постоянной важностью, следует сделать элементом VOB как можно раньше. Однако разработчикам позволяется многократно использовать представления, если в каждый момент времени это представление выделено для одной ветви, начиная с создания ветви и заканчивая прекращением ее использования. SDB не накладывает жестких ограничений на срок жизни представления. Когда проект закрывается, он должен уничтожить все свои представления.
Правило "Одно представление - один отдел - одна задача" порождает ветви с коротким сроком жизни. Благодаря этому ветвление более чем на один уровень ниже основной ветви является редким случаем. Также редко встречаются ветви, зависящие от другой ветви. Поэтому спецификации конфигураций представлений обычно просты. Они обычно похожи на следующие три правила:
element * CHECKEDOUT
element * .../branch/LATEST
element * /main/LATEST -mkbranch branch
Короткоживущие ветви содержат мало изменений и не вызывают много проблем при слиянии с основной ветвью. Также они способствуют раннему слиянию задач с основной ветвью. Задача становится видимой другим проектам для включения и тестирования вскоре после ее выполнения. У задачи есть больше возможностей пройти много циклов тестирования до того, как она станет частью рабочего продукта.
Но у правила "Одно представление - один отдел - одна задача" есть один недостаток. Оно генерирует большое количество короткоживущих ветвей. Поэтому для управления слиянием множества небольших ветвей с основной ветвью понадобился определенный процесс. В SDB решили ограничить слияния и делать их раз в неделю, по четвергам. Разработчики должны предоставить свои ветви для слияния до окончания рабочего дня в среду. В четверг в течение дня библиотекарь проводит слияние предоставленных ветвей. Он проверяет создание и запуск новой базовой линии. Затем, после окончания рабочего дня в четверг, библиотекарь регистрирует слияние (и тем самым делает его видимым для всей группы). Он присваивает новой базовой линии метку версии интеграции и выпускает для группы примечания к версии. В соответствии со стратегией проталкивания версий, пятница теперь становится днем, когда проекты объединяются с основной ветвью и перестраиваются. Пятница дает проектам множество преимуществ. Проектная группа может решить выполнять слияние в конце дня и сборку на выходных. Тогда ее участники вернутся в понедельник и найдут для оценки свежую сборку. Если у проектной группы есть задачи на следующую неделю, которые не хочется переносить, участники группы могут провести слияние утром в пятницу.
Если разработчики столкнутся с конфликтом с новыми изменениями, который они не смогут разрешить к концу дня, у них есть возможность разрешить этот конфликт в выходные. Тогда они в понедельник проект будет готов для новых действий. Если новая базовая линия содержит дефект, влияющий на множество проектов, и этот дефект нельзя исправить к концу дня в пятницу, то выбранные инженеры и библиотекари могут за выходные разработать исправление. Тогда исправленная базовая линия будет готова для проектов в понедельник утром.
Как правило, этот процесс слияния нацелен на понедельник-вторник как самые продуктивные дни для проектов.
В SDB ограниченное количество ресурсов развертывания (таких как имитаторы, лаборатории интеграции и исследовательские самолеты) для тестирования и производства систем. Для тестирования своих систем разработчики должны планировать время на этих ресурсах. Для максимального повышения эффективности использования отведенного им времени разработчикам требуется короткое время оборота для сборок. Разработчикам также нужно работать без помех со стороны других проектов. Основная часть разработок в SDB - это ПО для исследований и имитации. Поэтому в качестве примера того, как SDB использует ClearCase для управления сборками, будет рассмотрена среда IRIX.
Разработчики SDB работают в совместной компьютерной среде, как показано на рис. 5. У разработчиков на рабочем столе установлен ПК. Но он используется просто как терминал удаленного доступа к пулу компьютеров SGI. Этот пул содержит мощный сервер SGI Origin 2000 с 8 процессорами и 8 ГБ ОЗУ. Он используется в качестве сервера представлений и основного хоста разработки. Набор компьютеров Onyx служит в качестве компьютеров развертывания для имитаций. Разработчики могут также регистрироваться в этих системах и использовать их для разработки, когда они не используются для рабочей имитации. Есть также несколько рабочих станций SGI меньшей мощности. Разработчики используют их для разработки. Поскольку вычислительные ресурсы используются совместно, SDB стремится иметь среду, где проектные группы могут беспрепятственно создавать продукты и тестировать их, не влияя на работу друг друга. Основными проблемами являются использование ресурсов сборками и запуск нескольких специализированных версий совместно используемых библиотек на одном компьютере. Для решения обеих проблем используется решение ClearCase.
Время сборки и дисковое пространство
Например, последовательная сборка типичного имитатора занимает 4,5 часа. (Последовательная сборка выполняет все действия сборки в одном процессе.) Другими словами, 4,5 часа эта сборка потребляет процессорные, дисковые и сетевые ресурсы. Сборка может расходовать также и человеческие ресурсы. Разработчики будут выполнять другие действия, не связанные с производством продукта, пока они ждут завершения сборки. Сборка также порождает 1 ГБ производных объектов. Требования ко времени сборки и дисковому пространству для отдельного продукта могут показаться мягкими. Но умножьте эти цифры на тридцать шесть разработчиков, каждый из которых работает над 1-3 проектами, и проблема становится понятной. Потенциальным решением является дополнительное и более быстрое аппаратное обеспечение. Но закупка оборудования для удовлетворения растущих потребностей ПО стоит дорого. Также ограничивающим фактором может стать резервное копирование файловой системы, поскольку технологии резервного копирования не успевают за ростом емкости дисков. Поэтому для решения этой проблемы в SDB обратились к двум возможностям ClearCase, которые предоставляет утилита компоновки clearmake. Это совместно используемые производные объекты и параллельные распределенные сборки.
Рисунок 5. Совместно используемая компьютерная среда SDB.
Clearmake предоставляет возможность совместно использовать в одном или нескольких представлениях один и тот же производный объект, если сборки в этих представлениях должны использовать одинаковые команды и версии файлов для сборки производного объекта. Эта функция включена по умолчанию. Проектная группа просто должна выполнить свой make-файл с помощью утилиты clearmake в представлении. SDB может эффективно совместно использовать производные объекты благодаря своему акценту на многократно используемые инфраструктуры. Например, продукты для имитации на 66-96% состоят из совместно используемого кода. Это означает, что более половины производных объектов в продукте для имитации можно позаимствовать из других проектов. Даже когда проект вносит модификации в совместно используемый код, правило "Одно представление - один отдел - одна задача" обычно приводит к появлению очень небольшого набора элементов, чьи версии видимы только этому проекту. Проект будет по-прежнему использовать большую часть производных объектов совместно используемого кода вместе с другими проектами.
Благодаря совместному использованию производных объектов последовательная сборка имитации выполняется всего за 26 минут. Это на порядок величины меньше, чем для сборки без совместного использования производных объектов. Одно только это значительно сокращает использование ресурсов и дает возможность сборки продуктов в обычное рабочее время. Совместное использование производных объектов также дает значительную экономию дискового пространства. На третьей неделе мая 2002 года в нашей среде было 46655 совместно используемых производных объектов. В это число были включены только производные объекты с двумя или более ссылками. Количество ссылок две и более означает, что производный объект активно используется как минимум двумя представлениями. Для активно используемых производных объектов среднее число ссылок составило 3,6. Производные объекты с одной ссылкой не учитывались. Эти объекты совместно использовались когда-то в прошлом, но сейчас используются только одним представлением. Благодаря совместному использованию производных объектов экономия дискового пространства составила 12,5 ГБ. Этого достаточно, чтобы разместить 12 продуктов для имитации. Возможность параллельно-распределенной сборки, которая есть в утилите clearmake, позволяет еще больше сократить время сборки. Обычно clearmake может разбивать большие порции сборки на несколько независимых процессов. Также в clearmake есть возможность распределить эти процессы среди других хостов ClearCase. Хост-файл сборки определяет список других допустимых хостов сборки. Хост-файл сборки - это текстовый файл, который разработчик создает в своем домашнем каталоге. Каждый хост указывается в отдельной строке. Clearmake также предоставляет средства управления, которые предотвращают переполнение компьютера распределенными сборками. На каждом компьютере может присутствовать файл bldserver.control. Этот файл может содержать пороговое значение простоя. Компьютер примет новый процесс сборки только в том случае, если его значение простоя выше заданного значения. Если простой ниже заданного значения, то компьютер отклонит процесс сборки. Тогда clearmake попытается выполнить процесс на другом хосте.
Параллельно-распределенная сборка особенно полезна в компьютерной среде SDB. Большинство разработчиков стремится использовать самую мощную систему, Origin 2000. Параллельно-распределенная сборка в clearmake позволяет разработчикам задействовать неиспользуемые компьютеры в среде, не регистрируясь на них. Предполагается, что у каждого разработчика есть файл хостов сборки, где перечислены все компьютеры SGI в среде. Тогда их сборки будут распределены среди этих компьютеров в сети и не будут переполнять систему Origin 2000. При распараллеливании на два компьютера в SDB наблюдалось сокращение времени сборки на 15-40%. Разброс связан с работой других компьютеров и сети, а также распределения сборок, поскольку в среде есть разные компьютеры с разной производительностью. В отличие от совместного использования производных объектов, это сокращение не приводит к снижению использования вычислительных мощностей. На самом деле оно несколько увеличивается по сравнению с последовательными сборками. Но при этом использование ресурсов на самой загруженной системе уменьшается. Это снижает влияние, которое сборки оказывают на другие действия, которые выполняет этот компьютер.
Основное преимущество параллельно-распределенных сборок - это улучшение использования человеческих ресурсов. Время ожидания сборок уменьшается. Благодаря этому у разработчиков появляется больше времени на создание продуктов.
Конфликты совместно используемых библиотек
Конфликты совместно используемых библиотек - это еще одна проблема, с которой сталкиваются разработчики в совместно используемой компьютерной среде. В любой заданный момент времени в различных представлениях могут существовать различные варианты одной и той же совместно используемой библиотеки. Большинство проектов, находящихся в разработке, будет использовать библиотеку исходя из последних версий совместно используемого кода в основной ветви. Проекты, проходящие тестирование продукта, могут использовать библиотеки старых версий. Проекты, занятые модификациями в совместно используемом коде, будут использовать библиотеку, основанную отчасти на версии ветви. Все эти проекты могут быть зарегистрированы на одном и том же компьютере, каждый для запуска своего продукта.
Потенциально это может привести к конфликту совместно используемых библиотек. По умолчанию ОС предполагает, что библиотеки с одинаковым именем являются одинаковыми. Также по умолчанию компоновщики в качестве имени библиотеки используют только имя файла (а не абсолютный путь к нему). При настройках умолчанию все проекты создадут свои библиотеки с одинаковым именем, но состоящие из различных наборов версий. При запуске каждым проектом своего продукта ОС будет привязывать этот продукт к библиотеке, выбранной для первого запущенного продукта. Библиотека, выбранная для первого продукта, может и не быть той библиотекой, которая ожидается для использования во всех последующих продуктах. Это и есть конфликт. Например, имитационные программы в SDB используют библиотеку под названием libsim.so. Проекты FIRST и NEXT регистрируются на одном компьютере с целью тестирования своих имитаторов. Проект FIRST создал свою библиотеку libsim.so, используя последние версии кода в основной ветви. Проект NEXT внес улучшения в некоторые файлы, которые использовались для создания библиотеки libsim.so. Некоторые версии, которые использовались для создания библиотеки libsim.so проекта NEXT, существуют в другой ветви. Проекты FIRST и NEXT при создании библиотеки libsim.so использовали поведение компоновщика, заданное по умолчанию. Поэтому оба экземпляра библиотеки получили название libsim.so. Проект FIRST запускает свою программу. Проект NEXT также вскоре после этого запускает свою программу. Продукт проекта NEXT требует, чтобы ОС связала его с библиотекой libsim.so. ОС видит, что библиотека libsim.so уже загружена, и связывает продукт проекта NEXT с библиотекой libsim.soпроекта FIRST. Разработчики проекта NEXT будут гадать, почему они не видят эффекта от своих изменений.
Из-за прозрачности ClearCase переход к абсолютным (указанным относительно корневого каталога) именам не является решением. Хотя проекты FIRST и NEXT будут иметь разные спецификации конфигураций и выберут разные наборы версий, абсолютные пути в двух представлениях для компоновщика останутся одинаковыми. В данном примере исходный код расположен в каталоге VOB /vobs/simulation, а make-файл размещает библиотеку в каталоге /vobs/simulation/libraries. Таким образом, компоновщик, получивший указание использовать абсолютный путь, назовет каждую библиотеку /vobs/simulation/libraries/libsim.so. Это имя останется одинаковым для продуктов проектов FIRST и NEXT. Конфликт по-прежнему существует. К счастью, ClearCase предоставляет путь, дифференцированный с точки зрения представления. Он добавляет к абсолютному пути префикс, содержащий имя представления. Этот префикс имеет вид /view/ имя_представления . Такой путь называется расширенным путем представления. Он позволяет дать каждой библиотеке имя, дифференцированное по представлению. Самым безопасным механизмом применения такого пути является переменная среды $(CLEARCASE_ROOT). Переменная $(CLEARCASE_ROOT) содержит расширенный префикс представления, добавленный к абсолютному пути. Его можно добавить к команде link, чтобы определить для библиотеки имя, дифференцированное по представлению. Ниже приведен пример цели в make-файле с использованием переменной $(CLEARCASE_ROOT).
/vobs/simulation/libraries/libsim.so: \ $(LIBSIM_DEPENDENCIES) @CC
-shared -Wl,-soname,$(CLEARCASE_ROOT)$@ -o $@ $^ |
Хотя в результате выполнения команды создается совместно используемая библиотека с дифференциацией имени относительно представления, правила make-файла остаются с точки зрения представления нейтральными. Цели и зависимости используют абсолютные пути, а не пути, дополненные представлением. Таким образом, правило make-файла для компоновки программы будет содержать зависимости совместно используемой библиотеки, которые идентифицируются только по их абсолютным путям. Компоновщик, однако, привяжет программу к совместно используемой библиотеке с использованием пути, дополненного представлением, который хранится внутри библиотеки. При запуске программы она затребует динамическую ссылку на библиотеку, используя свой путь, дополненный представлением. При запуске проектами программ из различных представлений не возникнет никаких конфликтов библиотек. У этого подхода есть недостаток: ни одна из совместно используемых библиотек не дает возможности получать доступ к любому производному объекту (wink-in). Использование корневого каталога, дополненного представлением, в команде компоновщика гарантирует, что конфигурационная запись для каждой библиотеки всегда будет уникальной. В зависимости от ОС может быть доступно и другое решение, которое сохраняет возможность доступа к совместно используемым библиотекам. Некоторые ОС позволяют каждому пользователю указывать свой собственный путь поиска совместно используемых библиотек объектов. Пользователь может добавить к своему пути поиска префикс в виде пути, дополненного представлением. Для безопасной работы ОС должна предоставлять пользователю средства автоматизации изменения пути поиска и установки представления, чтобы путь указывал на активное представление. Отладка такой автоматизации может потребовать большой работы методом проб и ошибок. Ограничения ОС на длину путей поиска могут также потребовать использования библиотек, расположенных рядом (даже если их исходный код существует в различных VOB), а также могут ограничить возможность для пользователей использовать вложенные оболочки представлений. В SDB сочли решение с компоновщиком самым простым и безопасным. Потерю возможности доступа к производным объектам библиотек посчитали незначительной ценой за это.
SDB реализует с помощью ClearCase четыре функции: 1) полномочия на изменения, 2) выпуск версий ПО, 3) реализация изменений и 4) управление сборками.
В SDB есть две категории ПО с различными полномочиями на изменения: проектное ПО и совместно используемое ПО. Однако проекты выполняют все сопровождение совместно используемого ПО. Все модификации в совместно используемое ПО выполняются в рамках работы над проектами. Поэтому проект должен иметь возможность изменять совместно используемое ПО, но видимость изменений должна оставаться под контролем организационных полномочий на изменения. SDB предоставляет раздельные полномочия на изменения, разделяя совместно используемый код и код проекта по своим собственным VOB. Назначенные библиотекари контролируют видимость изменений в VOB для совместно используемого кода путем блокировки основной ветви. Каждый лидер проекта обладает полномочиями на VOB своего проекта. Чтобы дать возможность проектам изменять совместно используемый код в контексте проектной работы, VOB для проектного и совместно используемого кода используют БД AdminVOB. AdminVOB предоставляет глобальные метки и глобальные ветви, где хранятся версии и модификации, которые распространяются на несколько VOB. Таким образом, задачи, в которые вовлекается совместно используемый и проектный код, можно идентифицировать с помощью одной ветви. Проекты могут беспрепятственно определять глобальные метки и ветви. Они могут также беспрепятственно применять ветви к совместно используемому коду с целью его модификации.
Сделав всех разработчиков ответственными за сопровождение совместно используемого кода, SDB стремится избежать разделения совместно используемого кода на две или более конфигурации со своими собственными сообществами пользователей. Для предотвращения подобного разделения в SDB разработали специальные стратегии выпуска версий ПО и внедрения изменений. В стратегии "проталкивания" версий проекты, находящиеся в стадии разработки, должны использовать последнюю версию в основной ветви. Разработчиков "подталкивают" принимать и оценивать последние изменения при написании кода. Таким образом, старые версии не собирают сообществ пользователей. Подобное сообщество в конце концов оказалось бы в положении, когда исправление старой версии обходится дешевле, чем переход на новую версию. В результате возникает отклоняющаяся базовая линия. Подталкивание разработчиков к принятию изменений исключает эту возможность.
Принятие изменений не работает, если проекты также не вынуждают совместно использовать изменения регулярно и на ранних этапах. Поскольку изменения в совместно используемом коде по определению полезны для других проектов, проект, который накапливает свои изменения совместно используемого кода в отдельной ветви, в конечном итоге обнаружит, что другие пользователи мигрировали в другую ветвь. Правило "Одно представление - один отдел - одна задача" содействует передаче разработчиками своих изменений в совместное использование часто и небольшими частями. Разработчики должны делить свои изменения на небольшие связные задачи и передавать каждую задачу для слияния после ее выполнения. Слияние делает изменения доступными остальным разработчикам. Ветвь, хранящая эту одну задачу, затем должна отбрасываться, а следующая задача получает свою собственную ветвь. Необходимость для других проектов работать на базе существующей ветви, отличной от основной, сокращается.
Группа разработчиков работает в совместно используемой компьютерной среде с ограниченными ресурсами развертывания для системного тестирования. Для тестирования своих систем разработчики должны запланировать время на этих ресурсах. Для максимально эффективного использования отведенного им времени разработчикам требуется сжатый цикл обработки исправлений кода. Ночное выполнение сборок не практикуется. Разработчикам также нужно работать без помех со стороны других разработчиков. Совместное использование производных объектов и параллельно-распределенные сборки обеспечивают быстрый цикл обработки изменений кода. Вместе они снижают общее использование ресурсов и обеспечивают баланс использования вычислительных ресурсов. Разработчики, работающие с ресурсами развертывания, как правило не испытывают задержек из-за высокой загрузки компьютеров. Также в SDB именуют совместно используемые библиотеки объектов с использованием путей, дополненных представлением. Такое именование предотвращает конфликты между совместно используемыми библиотеками. На одном компьютере могут работать несколько проектов, использующие разные вариации совместно используемых библиотек объектов. При этом можно не бояться, что ОС свяжет программу с ранее загруженным вариантом библиотеки из другого проекта.
1 Не путать с базовой линией UCM. Термин "базовая линия", используемый здесь, следует определению в стандарте IEEE Std 610: IEEE Standard Glossary of Software Engineering Terminology (Стандартный словарь терминологии разработки ПО группы IEEE) . "Базовая линия" - это согласованный набор версий, относительно которых должны быть одобрены изменения.
2 Для ответственных проектов NASA может предоставить персонал для обеспечения качества и независимой проверки и утверждения (independent verification and validation, IV&V) извне SDB. Однако такой режим работы не является обычным.
3 Качество кода не является проблемой при переходе от проектного кода к совместно используемому, поскольку действия по обеспечению качества унифицированы для проектного и совместно используемого кода. Поскольку проектные группы отвечают и за проектный, и за совместно используемый код, единый процесс обеспечения качества удобнее для разработчиков. Это легче, чем заставлять их "прыгать" между двумя процессами в зависимости от того, какой файл они открыли. В SDB есть организационные стандарты для стиля написания кода, первичного анализа проекта, критического анализа проекта, анализа кода и тестирования модулей. Поскольку среди персонала нет разделения ролей, разработчик отвечает за инициирование всех этих действий. Ответственность за код не переходит из рук в руки. Поэтому мы не используем ClearCase для отслеживания, прошел ли код эти стадии работ. Вместо этого мы используем систему, основанную на доверии. Когда разработчик передает свой код для добавления в публично видимую версию ПО, он должен указать, что следовал этим процессам (или получил разрешение на отход от них), заполнив контрольный список.
4 В число участников экспертного анализа входят и другие проектные группы, поэтому экспертная оценка обеспечивает предварительный просмотр планируемых изменений. Но другие проекты обычно не используют возможность тестировать эти изменения для своих собственных продуктов, пока не будет установлена базовая линия интеграции.
5 Напомним, что в совместно используемых VOB основная ветвь блокируется, чтобы предотвратить внесение в проекты неполных или непротестированных изменений.