Управление конфигурациями проекта с помощью AllFusion Harvest Change Manager
© А. Козодаев
Введение
В современных условиях организациям-разработчикам программного обеспечения на всех стадиях жизненного цикла разработки программного обеспечения приходится сталкиваться с непрерывным потоком изменений программного кода. Однако конкурентная среда вынуждает организацию сокращать время выхода продукта на рынок, при этом ужесточаются требования к количеству ошибок в программном коде финальных релизов новых версий программ. Возникает некий парадокс, когда уменьшение времени разработки не способствует улучшению качества кода, однако для сохранения возможности выпускать конкурентоспособное программное обеспечение количество ошибок должно быть сокращено до минимума, в идеале до нуля. К тому же всевозрастающая сложность нового программного обеспечения вынуждает разработчиков использовать многие платформы и различные среды разработки. Решением данной проблемы должен быть специальный продукт, позволяющий отслеживать изменения в рамках распределенной структуры разработки программного обеспечения с использованием различных платформ и сред разработки. Немаловажным условием коммерческого успеха организации-производителя является возможность обеспечить организованный и управляемый процесс производства программного обеспечения. Постепенно этот процесс принимает все более четко очерченные границы и начинает подчиняться правилам и методам, и все менее похож на шаманство.
Одним из наиболее распространенных стандартов, следование которым помогает организациям строить более качественное ПО, является модель зрелости разработки программного обеспечения (Software CMM), и развитие этого стандарта - интегрированная модель зрелости процессов (CMMI - capability maturity model integration). Важной составляющей этой модели является конфигурационный и версионный менеджмент. Сертификация по системе CMMI дает разработчикам серьезные преимущества при работе с западным заказчиком. Таким образом, желательно, чтобы продукт выполнял не только элементарные функции хранения конфигураций и версий кода, но и органично встраивался в процесс разработки программного обеспечения.
Одним из таких инструментов является программное средство, производимое компанией Computer Associates - AllFusion Harvest Change Manager.
Далее в статье будут рассмотрены:
- архитектура продукта - для понимания того, каким образом организуется работа со многими платформами и различными средами разработки.
- объекты и внутренняя терминология Harvest - для понимания того, каким образом Harvest встраивается в процесс производства программного обеспечения.
- механизмы 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 можно разбить на две категории:
- задачи администрирования, к таким относятся: определение жизненного цикла и его свойств, управление пользователями, создание репозитория и некоторые другие. Такого рода задачи решаются администратором, и для этого используется Harvest Administrator.
Рисунок 3. Интерфейс Harvest Administrator.
- повседневные задачи, к ним можно отнести те действия, которые выполняются конечными пользователями 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 шаблонов жизненного цикла, которые администратор может использовать как основу для создания своего собственного типа жизненного цикла.
| Наименование шаблона |
Предназначение шаблона |
| Standard problem tracking |
Управление запросами на изменение. Создание запроса, время на исследование изменения и его этапы. |
| Formal problem tracking |
Расширенная модель управления запросами на изменение. |
| Version Control |
Организация версионного контроля и отслеживание версий программного кода. |
| New development |
Шаблон для создания нового программного обеспечения. |
| Release |
Шаблон для выпуска окончательной версии (релиза) программного обеспечения. |
| Parallel Development |
При разработке новой версии (релиза) продукта необходимо также поддерживать предыдущие версии продукта. Данный шаблон помогает это осуществить. |
| Production |
Шаблон Production позволяет контролировать изменения между рабочими версиями продукта. |
| Third-Party Software |
Шаблон, необходимый для связывания программного обеспечения сторонних разработчиков с собственными проектами. |
| Electronic Software Distribution |
Шаблон для использования в системах электронной дистрибуции программного обеспечения. Электронная дистрибуция программного обеспечения позволяет упростить процесс дистрибуции (передачи) программ и файлов данных на множество целевых (клиентских) компьютеров. Однако настройка такой системы является нетривиальной задачей и немаловажным фактором функционирования системы является организация конфигурационного менеджмента и контроля версий. |
| HelpDesk Integration |
Модель управления изменениями для службы Help Desk, позволяющая обмениваться информацией между различными приложениями службы Help Desk, к примеру, такими как AutoAnswer. |
| Packaged Application Change Management |
Этот шаблон используется для документирования изменений в системах класса: Oracle Financials, PeopleSoft, SAP R/3. В подобных системах очень велик риск использования непроверенных изменений, которые могут неблагоприятно сказаться на общем функционировании системы или привести к ее краху. |
Каждому состоянию проекта соответствует набор процессов, которые связаны с изменениями программного кода. В задачи администратора входит определение набора процессов для каждого состояния проекта и предоставление пользователям и группам пользователей прав на выполнение того или иного процесса. В Harvest предопределен набор стандартных процессов, которы е администратор может взять за основу.
| Тип процесса |
Описание процесса |
| Approve |
Данный процесс позволяет определенным пользователям подтвердить либо отклонить пакет для последующего перемещения пакета на следующий этап проекта либо возврата на предыдущий. |
| Check In |
Процесс, позволяющий скопировать файлы с клиентского компьютера в репозиторий Harvest, создавая тем самым новые элементы репозитория, либо обновляя существующие. |
| Check Out |
Процесс копирования элементов репозитория на клиентский компьютер. |
| Compare Views |
С помощью данного процесса создается отчет о различиях в двух отображениях, сравниваемые отображения могут быть как рабочими, так и моментальными снимками. |
| Concurrent Merge |
Использование данного процесса возвращает версию элемента с ветви дерева версий на ствол дерева версий. |
| Create Package |
Данный процесс создает пакет, в рамках которого отслеживаются изменения программного кода. Если в свойствах процесса указана опция автоматического создания формы, то создается форма, ассоциированная с пакетом. |
| Cross Project Merge |
Этот процесс необходим для слияния изменений элементов, сделанных в одном проекте с изменениями тех же самых элементов в другом проекте. |
| Delete Version |
Процесс удаления версии элемента, хранящегося в репозитории Harvest; данный процесс имеет ряд ограничений среди которых:
- удалить можно только последнюю версию элемента
- версия не может быть удалена, если она существует в нескольких отображениях
- некоторые другие ограничения.
|
| Demote |
В состав Harvest включены два процесса, с помощью которых пакеты перемещаются между состояниями проекта. С помощью процесса Demote осуществляется перенос пакета с текущего состояния проекта на предыдущее.
Interactive Merge С помощью этого процесса объединяются изменения, сделанные в версиях элементов в ветвях дерева версий с версиями изменений на стволе. |
| List Version |
При помощи данного процесса создается отчет об изменениях версий элемента репозитория в рамках текущего проекта. |
| Move Package |
Процесс Move Package необходим для перемещения пакета из одного состояния проекта в одно из состояний другого проекта. При этом перемещаются лишь описание пакета и его история, элементы пакета не могут быть перемещены. Этот тип процесса используется в основном для связи пакетов между проектами. |
| Notify |
Процесс, используемый для отсылки сообщений по электронной почте пользователю либо группе пользователей. |
| Promote |
Процесс для переноса пакета либо группы пакетов с текущего состояния проекта на следующее состояние. |
| Remove Item |
Процесс логического удаления выбранных элементов. Фактически этот процесс создает новую версию выбранного элемента и в дальнейшем для восстановления этого элемента необходимо удалить версию с пометкой удаления. |
| Rename Item |
Процесс переименования элемента. В процессе переименования элемента создается новая версия элемента. Все предыдущие версии элемента отображаются под старым именем элемента. |
| Take snapshot |
Процесс создания отображения типа моментальный снимок из рабочего отображения. |
| User-defined process |
В качестве процесса, определенного пользователем, можно использовать внешнюю программу, которая будет выполняться как процесс в рамках текущего жизненного цикла. |
Итак, рассмотрим краткий пример использования Harvest. В организации, разрабатывающей программное обеспечение, стоит задача наладить конфигурационный и версионный менеджмент.
На первоначальном этапе выделяется лицо, ответственное за администрирование Harvest. Администратор разрабатывает жизненный цикл, который включает в себя следующие состояния:
- Assign - на этом этапе создаются запросы на изменение (пакета), запросы могут быть созданы любым пользователем Harvest. Существует специальная роль менеджер разработки (development manager), который ответственен за присваивание каждому запросу приоритета и переназначение каждого пакета определенному разработчику.
- Coding - на этом этапе разработчики вносят все необходимые изменения в программный код в соответствии с поступившими запросами на изменения. По завершении кодирования менеджер разработки проверяет измененный пакет и переводит его в следующее состояние проекта.
- Test - в рамках этого состояния проекта тестировщик просматривает запрос на изменение и тестирует изменения в программном коде сделанные разработчиком на предыдущем состоянии. В случае отсутствия ошибок пакет переводится на следующее состояние проекта, в противном случае пакет возвращается в предыдущее состояние.
- Release - в рамках данного состояния хранятся все авторизованные изменения проекта. Когда вся совокупность программного кода готова к выпуску в качестве финального релиза, имеет место процесс создания моментального снимка.
- Snapshot - в пределах этого состояния хранятся все моментальные снимки проекта, с помощью моментальных снимков возможно просмотреть совокупность программных активов на любой момент развития проекта.
Далее администратором создаются пользователи и группы пользователей.
| Группа пользователей |
Пользователь |
| Development Manager |
development manager |
| Developer |
developer1 |
| developer2 |
| QA |
quality manager |
Следующим шагом является создание проекта и рабочих отображений. Администратор создает проект и три рабочих отображения.
| Состояние |
Отображение |
| Assign |
не используется
|
| Coding |
Dev |
| Test |
Test |
| Release |
Closed |
| Snapshot |
используются все моментальные снимки |
На следующем этапе администратор создает ряд процессов для каждого состояния.
| Состояние |
Название процесса |
Тип процесса |
| Assign |
Create Package |
Create Package |
| Promote to Coding | Promote |
| Coding |
Approve Package |
Approve |
| Check in Changes |
Check-in |
| Check out |
Check-out |
| Concurrent Merge |
Concurrent Merge |
| Interactive Merge |
Interactive Merge |
| List Version |
List Version |
| Promote to Test |
Promote |
| Test |
Check out |
Check-out |
| Compare Views |
Compare Views |
| Delete Version |
Delete Version |
| Demote to Coding |
Demote |
| Promote to Release |
Promote |
| Remove Item |
Remove Item |
| Release |
Take Snapshot View |
Take Snapshot
|
| 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 одним из лучших средств конфигурационного менеджмента и версионного контроля, мы хотели бы выделить следующие:
- гибкая масштабируемость продукта позволяет использовать его как в небольших проектах по разработке программного обеспечения, так и строить на основе Harvest систему конфигурационного и версионного контроля для всего предприятия;
- упрощение функций конфигурационного менеджмента путем введения единой точки управления действиями по изменению программного кода;
- возможности Harvest помогают организации достичь определенного и повторяемого процесса разработки программного обеспечения, что является немаловажным фактором в производстве качественного ПО;
- гибкий и удобный в использовании интерфейс;
- встроенные элементы версионного контроля;
- интерактивная утилита слияния версий, позволяющая в визуальном виде разрешать конфликты между версиями пакетов;
- автоматизация проектной документации посредством форм Harvest и мощных средств для построения отчетов;
- поддержка многих платформ и сред разработки;
- AllFusion Harvest Change Manager сертифицирован на соответствие стандарту ITIL.
Дополнительная информация
Форум по продуктам Computer Associates
