Управление конфигурациями проекта с помощью AllFusion Harvest Change Manager

Оглавление

• Введение
• Архитектура Harvest Change Manager
• Иерархия объектов Harvest Change Manager
• Дополнительная информация

Введение

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

Одним из наиболее распространенных стандартов, следование которым помогает организациям строить более качественное ПО, является модель зрелости разработки программного обеспечения (Software CMM), и развитие этого стандарта - интегрированная модель зрелости процессов (CMMI - capability maturity model integration). Важной составляющей этой модели является конфигурационный и версионный менеджмент. Сертификация по системе CMMI дает разработчикам серьезные преимущества при работе с западным заказчиком. Таким образом, желательно, чтобы продукт выполнял не только элементарные функции хранения конфигураций и версий кода, но и органично встраивался в процесс разработки программного обеспечения.

Одним из таких инструментов является программное средство, производимое компанией Computer Associates - AllFusion Harvest Change Manager.

Далее в статье будут рассмотрены:

1. архитектура продукта - для понимания того, каким образом организуется работа со многими платформами и различными средами разработки.
2. объекты и внутренняя терминология Harvest - для понимания того, каким образом Harvest встраивается в процесс производства программного обеспечения.
3. механизмы Harvest , реализующие функции версионного контроля и конфигурационного менеджмента.

Архитектура Harvest Change Manager

Harvest Change Manager - клиент-серверное приложение, построенное для поддержки распределенных сред разработки с использованием различных платформ. Ниже на рисунке представлены основные компоненты архитектуры Harvest. Из всех составных частей архитектуры необходимо выделить следующие:

- клиентская часть (Client) состоит из графического интерфейса (GUI) и интерфейса командной строки (CLI). MVS/ISPF интерфейс необходим для выполнения пользовательских функций из OS/390. Фактически клиентская часть - это интерфейс для передачи данных, введенных пользователем в серверную часть.

Рис. 1. Архитектура Harvest Change Manager

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

- коммуникационный уровень (Communication Layer) - это набор протоколов для связи серверной части с клиентской и обеспечения взаимосвязанной работы всех компонентов Harvest.

Частью коммуникационного уровня является Harvest broker. Эта специальная программа для связи клиента с необходимым сервером (в сети может быть как множество клиентов, так и множество серверов Harvest). Каждый сервер регистрируется в Harvest broker и предоставляет всю информацию, необходимую для связи клиента с сервером.

Иерархия объектов Harvest Change Manager

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

Рис. 2. Иерархия объектов в Harvest Change Manager

• Репозиторий (repository) - центральное хранилище элементов конфигурации, которые находятся под управлением Harvest.
• Элемент (item) - единичная структура данных, хранящихся в репозитории Harvest.
• Проект (project) - это специфический экземпляр жизненного цикла для разработки или поддержания определенного типа приложения. Проект включает в себя информацию об изменениях программного кода, о трансформации изменений в рамках жизненного цикла. В нем содержится также информация о действиях, вызывающих изменения программного кода, о пользователях, которые инициируют процесс изменения, и которые за него отвечают. Проект включает в себя следующие понятия: состояния, пакеты и группы пакетов, процессы, отображения и формы.
• Состояние - это стадия или фаза проекта, в которой происходят определенные процессы, изменяющие программный код приложения. Проект может состоять из целого ряда состояний. Как правило, состояние связано с отображением.
• Отображение (view) - это набор элементов и их версий, хранящихся в репозитории и доступных для просмотра на определенном этапе жизненного цикла. Существует несколько видов отображений: базовая линия (baseline), рабочее отображение (working view), моментальный снимок (snapshot).
• Базовая линия - это отображение, доступное на любом этапе жизненного цикла, фактически это набор всех элементов данного проекта. Элементы в базовом представлении имеют нулевую версию. Базовая линия создается в начале проекта.
• Рабочее представление - это частный случай базовой линии, набор тех же элементов, которые включены в базовую линию, однако версии элементов могут отличаться от тех, что хранятся в базовом представлении. Рабочее представление интегрировано в жизненный цикл разработки посредством ассоциирования с состоянием проекта. Несколько состояний могут быть связаны с одним рабочим представлением, однако состояние не может быть основано более чем на одном рабочем представлении.
• Последним видом представления является моментальный снимок - это набор всех элементов проекта в определенный момент времени.
• Процессы - это действия, осуществляемые над объектами, хранящимися в Harvest.
• Harvest предоставляет предопределенный набор процессов, каждый из которых может быть связан с определенным состоянием. Помимо стандартных процессов пользователь может создать свои собственные процессы. С помощью процессов реализуются функции конфигурационного менеджмента и версионного контроля.
• Версии - это механизм, используемый Harvestом для отслеживания и контролирования изменений, сделанных над элементом, хранящимся в репозитории. Версии идентифицируются по номеру. Номер версии увеличивается при каждом изменении элемента.
• Пакет - это логическая структура, в контексте которой отображаются изменения элементов. Пакет представляет собой проблему либо запрос на изменение. Каждый пакет может состоять как из одного, так и из многих изменяемых элементов.
• Группа пакетов представляет собой логическую группировку пакетов с целью упрощения манипулирования ими. Действия, которые могут быть выполнены над пакетом, также могут быть выполнены и над группой пакетов.
• Формы в Harvest во многом подобны бумажным формам. Они используются для отслеживания изменений и проблем, а также в качестве структурированного метода коммуникации между участниками проекта. Информация о формах хранится в базе данных и может быть использована для построения пользовательских отчетов. Наиболее оптимально использовать формы в контексте пакетов.

Задачи, решаемые при помощи Harvest Change Manager можно разбить на две категории:

1. задачи администрирования , к таким относятся: определение жизненного цикла и его свойств, управление пользователями, создание репозитория и некоторые другие. Такого рода задачи решаются администратором, и для этого используется Harvest Administrator.

   

   Рисунок 3. Интерфейс Harvest Administrator.

2. повседневные задачи , к ним можно отнести те действия, которые выполняются конечными пользователями Harvest: это создание пакетов, извлечение информации из репозитория (процесс Checkout), сохранение извлеченной информации в репозиторий (процесс Checkin) и многие другие действия. В этом случае используется интерфейс Harvest Workbench.

   

   Рисунок 4. Интерфейс Harvest Workbench.

В состав Harvest входит Harweb - это веб-интерфейс, обеспечивающий выполнение как администраторских, так и повседневных задач. Harweb позволяет отказаться от использования Harvest Administrator и HarvestWorkbench.

Как уже было сказано ранее, функции Harvest Change Manager делятся на административные и повседневные. Для выполнения административных функций служит интерфейс Harvest Administrator. Основная доля административных функций выполняется на этапе внедрения Harvest Change Manager. На этом этапе выделяется, как правило, один пользователь, наделенный администраторскими правами (так как репозиторий Harvest строится на основе базы данных Oracle, для использования расширенных административных функций, таких как создание пользовательских форм и отчетов, необходимо знание основ администрирования баз данных Oracle).

К административным функциям можно отнести создание жизненного цикла, определение пользователей и групп пользователей и прав доступа к объектам - как для пользователей, так и для групп пользователей. Создание жизненного цикла предполагает определение состояний, из которых состоит жизненный цикл, и определение процессов, принадлежащих каждому состоянию. К определению жизненного цикла также относится создание репозитория и представлений данных (базового, рабочих и моментальных снимков). В состав Harvest Change Manager входит 11 шаблонов жизненного цикла, которые администратор может использовать как основу для создания своего собственного типа жизненного цикла.

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

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

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

• Assign - на этом этапе создаются запросы на изменение (пакета), запросы могут быть созданы любым пользователем Harvest. Существует специальная роль менеджер разработки (development manager), который ответственен за присваивание каждому запросу приоритета и переназначение каждого пакета определенному разработчику.
• Coding - на этом этапе разработчики вносят все необходимые изменения в программный код в соответствии с поступившими запросами на изменения. По завершении кодирования менеджер разработки проверяет измененный пакет и переводит его в следующее состояние проекта.
• Test - в рамках этого состояния проекта тестировщик просматривает запрос на изменение и тестирует изменения в программном коде сделанные разработчиком на предыдущем состоянии. В случае отсутствия ошибок пакет переводится на следующее состояние проекта, в противном случае пакет возвращается в предыдущее состояние.
• Release - в рамках данного состояния хранятся все авторизованные изменения проекта. Когда вся совокупность программного кода готова к выпуску в качестве финального релиза, имеет место процесс создания моментального снимка.
• Snapshot - в пределах этого состояния хранятся все моментальные снимки проекта, с помощью моментальных снимков возможно просмотреть совокупность программных активов на любой момент развития проекта.

Далее администратором создаются пользователи и группы пользователей.

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

На следующем этапе администратор создает ряд процессов для каждого состояния.

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

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

После настройки проекта администратором его могут начать использовать пользователи Harvest.

Ниже следует пример взаимодействия конечных пользователей с Harvest.

Приходит запрос на изменение от пользователя программного обеспечения. Пользователь Harvest при помощи процесса Create Package создает пакет First Package , в котором предоставлена вся необходимая информация, описывающая запрос на изменение. Менеджер разработки просматривает пакет, присваивает ему приоритет и назначает разработчика, который будет заниматься данным пакетом. В нашем случае новым пакетом будет заниматься разработчик Developer1. Если информация в пакете оформлена правильно, менеджер разработки переводит пакет при помощи процесса Promote to Coding на следующее состояние проекта. Разработчик Developer1 просматривает пакет, предварительно сохранив необходимые элементы Репозитория на свой компьютер при помощи процесса Check out , и изменяет программный код в соответствии с запросом на изменение. После этого он сохраняет измененный код в Репозиторий при помощи процесса Check in . Далее менеджер разработки просматривает изменения и переводит пакет на следующее состояние, воспользовавшись процессом Promote to Test . На следующем этапе тестировщик quality manager при помощи процесса Check out скачивает на свой компьютер пакет, измененный разработчиком, и тестирует его. Если тест проходит без ошибок, тестировщик переводит пакет при помощи процесса Promote to Release на состояние Release . Если же в результате теста обнаруживается ошибка, то пакет возвращается на предыдущее состояние при помощи Demote to Coding .

В любой момент в состоянии Release можно создать моментальный снимок, который будет отражать состояние проекта на определенный момент времени.

Одной из возможностей Harvest Change Manager является поддержка трех типов разработки программного обеспечения:

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

- одновременная разработка. Для обеспечения многопользовательского доступа к элементам используется процесс check out с опцией concurrent update , с помощью этого процесса создается ветвь в дереве версий.

Рисунок 5. Одновременная разработка.

После создания ветви дерева версий в ней фиксируются все версии изменений данного пакета. Для того чтобы перевести пакет с изменениями, сделанными в ветви, в другое состояние проекта, версии, находящиеся на ветви дерева версий нужно возвратить на ствол. Для этого используется стандартный процесс Concurrent Merge , он возвращает версию пакета с ветви на ствол дерева версий. При этом если на стволе уже существует более новая версия (V3), чем та, с которой началось ветвление (V2), то вновь полученная версия получает значение M. Для того, чтобы разрешить конфликты между версиями V3 и V4 используется процесс Interactive Merge Process , который в визуальном режиме позволяет сравнить конфликтуемые версии и выбрать нужный набор изменений. После этого процесса версия V4 теряет символ M.

- параллельный тип разработки позволяет вести работу одновременно над несколькими проектами и использовать в одном проекте версии пакета из другого проекта. Такой тип разработки позволяет создавать новый релиз программного обеспечения и при этом поддерживать текущий. Все изменения, производимые над текущим релизом (горячие патчи и т.д.) должны учитываться в новой финальной версии продукта. Для переноса пакета из одного релиза продукта в другой используется процесс Cross Project Merge .

Среди основных достоинств, которые позволяют назвать AllFusion Harvest Change Manager одним из лучших средств конфигурационного менеджмента и версионного контроля, мы хотели бы выделить следующие:

1. гибкая масштабируемость продукта позволяет использовать его как в небольших проектах по разработке программного обеспечения, так и строить на основе Harvest систему конфигурационного и версионного контроля для всего предприятия;
2. упрощение функций конфигурационного менеджмента путем введения единой точки управления действиями по изменению программного кода;
3. возможности Harvest помогают организации достичь определенного и повторяемого процесса разработки программного обеспечения, что является немаловажным фактором в производстве качественного ПО;
4. гибкий и удобный в использовании интерфейс;
5. встроенные элементы версионного контроля;
6. интерактивная утилита слияния версий, позволяющая в визуальном виде разрешать конфликты между версиями пакетов;
7. автоматизация проектной документации посредством форм Harvest и мощных средств для построения отчетов;
8. поддержка многих платформ и сред разработки;
9. AllFusion Harvest Change Manager сертифицирован на соответствие стандарту ITIL.

Дополнительная информация

• Подробнее о продуктах Computer Associates
• Подробнее о линейке интегрированных средств моделирования (CASE) - AllFusion Modeling Suite
• Обратиться в Interface Ltd. за дополнительной информацией/по вопросу приобретения продуктов
• Приобрести продукты Computer Associates в электронном магазине ITshop.ru
• Курсы по продуктам Computer Associates