Важным этапом производства программного обеспечения и, в частности, конфигурационного управления является эффективный менеджмент процессов сборки программных систем. Для того чтобы решить эту задачу, необходим не инструментарий нижнего уровня типа утилит make или популярного Ant, а именно системы управления. Такие системы отличаются гибкостью по отношению к специфике разрабатываемого ПО, «портфельным» подходом к проектам и ставкой на объединение инструментария с доступом к максимальному спектру функционала из единой графической оболочки.

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

Cистема Build Forge, входящая в линейку продуктов IBM Rational, призвана централизовать и оптимизировать разработку сложных приложений. Основное назначение системы – управление сборкой и релизами. При этом под сборкой понимается широкий набор автоматизируемых действий, от подготовки окружения до обработки результатов автоматического тестирования.

Build Forge

Суффиксная часть в названии системы выбрана не случайно и декларирует принадлежность к классу так называемых «кузниц кода» (Software Forge). Основоположником этого класса считается популярный портал SourceForge (sourceforge.net), «приютивший» огромную коллекцию разнообразных проектов с открытым кодом (подробнее см. статью «Кузницы кодов» – инструмент взаимодействия разработчиков» в этом выпуске журнала «Открытые системы«). Возникшая в сообществе Open Source идея была подхвачена и развита коммерческими компаниями (SAP, HP, Microsoft и IBM). С годами были сформированы общие принципы, след которых явно виден и в Build Forge. Например, пользователю «кузницы» обычно доступны следующие уровни интерфейса: навигация по «проектам» с поиском и фильтрацией; представление самого проекта для работы с ним, состоящее из списка доступных инструментов (команд) и рабочей области конкретного инструмента. Пользовательский интерфейс Build Forge следует классике разделения рабочего поля экрана на три фрейма: навигационная панель и две области редактирования объектов верхнего/нижнего уровня по аналогии с проектом/инструментами.

История Build Forge берет начало в 2002 году, когда одноименная компания выпустила первую версию продукта, постепенно завоевавшего рынок и по итогам 2005-го и 2006 годов попавшего
в престижный SD Times Top 100. Лауреаты этого списка ежегодно выбираются экспертами журнала Software Development Times (www.sdtimes.com) из числа коммерческих компаний и проектов с открытым кодом. При этом номинирование происходит по десятку категорий, связанных с разработкой программных систем (базы данных, интегрированные среды разработки, приложения для тестирования и т.д.), а основными критериями выбора являются инновационность и лидерство на рынке. Примерно в это же время IBM в лице подразделения Rational проявило интерес к продукту и начало процедуру приобретения. Отметим, что управление сборкой было довольно слабым местом линейки приложений Rational, и возможности отдельных приложений в этом направлении, например ClearCase, не могли удовлетворить требовательных пользователей. В 2006 году сделка была официально анонсирована, и новая версия вышла уже под брендом Rational 7.0, а в декабре 2008 года вышла версия 7.1.

Build Forge имеет классическую трехзвенную архитектуру. Продукт устанавливается по умолчанию с DB2 Express Edition, но поддерживаются также основные популярные СУБД: MySQL, Oracle, Sybase и Microsoft SQL Server. Все операции осуществляются с использованием браузера, что вполне вписывается как в современные реалии использования информационных систем, так и стратегию IBM – движение в направлении платформнонезависимых клиентов, на основе Eclipse или Web-доступа. Если добавить к этому поддержку репликации баз данных, Unicode и учет временных поясов пользователей, то будут явно видны реверансы создателей в сторону географически распределенных команд. Сам интерфейс динамичен за счет набравшего популярность AJAX, хотя и не локализован. Среди рекомендованных к использованию браузеров – Internet Explorer и Mozilla FireFox. Серверная часть работает на Apache.

Проблема выбора

Часто первый вопрос при выборе средства автоматизации звучит как «коммерческое или бесплатное ПО?», хотя вопрос поставлен некорректно – даже система управления сборкой из категории Open Source (например, Cruise Control, Maven) будет дорабатываться и поддерживаться своими силами, что уже подразумевает скрытую стоимость. Более того, стоимость с трудом поддается оценке с учетом рисков совместимости или сложности реализации. Часто рассматривается вариант с выбором решения уже проверенного производителя, скажем Microsoft (Team Foundation Build/Visual Team System). Или же группа кандидатов сужается за счет требований проекта – среды или языка разработки, методологии процесса и других специфичных факторов. Например, Electric Cloud работает со сборкой на базе make-файлов, а Anthill Pro – с Java-проектами. Но средние и крупные организации зачастую участвуют в проектах различных направлений или комбинируют в одной системе разнотипные компоненты. Как им решать задачу выбора?

При первом знакомстве видно, что разработчики из IBM сделали ставку именно на универсальность и широкий функционал, создав Build Forge как решение для требовательного корпоративного пользователя, которому надо управлять распределенной аппаратной и смешанной программной инфраструктурой.

Основные возможности

Современные сложные системы требуют не выделенную машину для сборки, а пул серверов, которые могут быть необходимы для сборки компонентов с несовместимым окружением, увеличения отказоустойчивости системы сборки или оптимизации использования аппаратных ресурсов. Централизованное управление окружением (environment) и настройка условий для динамического выбора серверов (selectors) значительно упрощают организацию всего процесса; это сильная сторона Build Forge. Причем выбор машины, наиболее подходящей по совокупности характеристик, можно делать хоть для каждого этапа сборки. Удаленный доступ к управляемым машинам осуществляется с помощью сервисов-агентов. Реализована широкая поддержка операционных систем: Windows, AIX, HP-UX, Sun Solaris, Red Hat Enterprise Linux, Mac OS, i5/OS и z/OS.

Проект сборки программы реализован в виде дерева этапов (Steps) и представляет собой формализованный процесс получения готового продукта. Встроенные режимы отладки отдельных этапов и повторное использование уже отлаженных фрагментов (libraries) сэкономят время при поддержке и совершенствовании программной части. В целях повышения производительности Build Forge предоставляет встроенные возможности управления параллельными потоками (threading), включая механизм семафоров, регистры для межпоточного обмена данными и условное выполнение этапов.

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

Поддержка SSL, интеграция с LDAP/Active Directory, шифрование трафика и паролей в логах дополняют джентльменский набор, без которого не обходится солидная корпоративная система.

Отдельного упоминания заслуживают журналы регистрации. Кто не пытался отыскать в мегабайтных текстовых файлах нужное место? А файлы, разбросанные по разным серверам? В Build Forge предусмотрена гибкая фильтрация общего журнального файла по уровням и этапам, которая позволяет отсеять кучу бесполезной информации, чтобы найти проблемы прямо в окошке браузера. Незначительной на первый взгляд, но важной особенностью является мониторинг сборки в режиме реального времени – приятнее наблюдать бегущий журнал на своем мониторе, чем перескакивать с одного сервера на другой или дергать коллег из соседнего отдела, да и прозрачность результатов для широкого круга пользователей влияет на ответственность и дисциплину. Иногда трудно контролировать результат без синтаксического анализа журнала, и здесь надо создать набор правил на основе регулярных выражений, объединить их в группы (Log Filters) и назначить тому или иному этапу. Дальнейшее развитие фильтров происходит централизованно для всех проектов и требует минимальных обучающих действий.

В Build Forge предусмотрена также возможность учета и получения контрольной информации о процессе сборки. Технология Bill of Materials позволяет собирать и управлять метаданными каждой сборки в виде древовидной структуры: содержимое релиза, контрольные суммы, настройки окружения, отчеты об изменениях, результаты автотестов и многое другое. Самая важная информация формируется автоматически, но с помощью внутренних команд можно обработать и перенаправить в Bill of Materials любые данные. Обычно это требуется для соответствия процесса разработки тому или иному стандарту, ведь фактически реализуется ведение журнала аудита (Audit Trail). Пригодится такая технология и в случае необходимости какой-либо информации в соответствии с организационной спецификой компании, обработки метрик или быстрого поиска необходимого релиза в базе. Заодно становится возможным проследить однозначный путь от проблемы до той версии файла, которая ее породила.

Дополнительно лицензируемый модуль Quick Report представляет собой инструмент для автоматизации создания шаблонов в Web-интерфейсе. Типичная для крупных проектов ситуация аврала, когда технические писатели обязаны в кратчайшие сроки перед релизом подготовить необходимые документы, может быть значительно разгружена благодаря средствам автоматизации получения документов с помощью Build Forge. Правда, если хотите на выходе иметь заготовку с Fixed Bugs/Known Issues, внутренний отчет о метриках исходного кода или результатах автоматического тестирования – не обойтись без интеграции с другими приложениями.

Интеграция с существующей инфраструктурой

Build Forge предлагает несколько вариантов интеграции в имеющуюся у разработчиков инструментальную инфраструктуру, и наиболее перспективным представляется механизм адаптеров, позволяющий через XML-интерфейс описать взаимодействие со сторонними системами, например версионного контроля или управления артефактами разработки. Однако для создания своего адаптера все равно потребуется хорошее владение внешними инструментами, прежде всего знание командной строки или API. Поставляемые адаптеры включают поддержку ClearCase, ClearQuest, CVS, Subversion, Microsoft SourceSafe, Perforce, StarTeam. Там, где возможностей адаптеров не хватает или они нецелесообразны, выручает наличие Java/Perl API и нескольких утилит командной строки. Это позволяет обрабатывать «внешние» события (постановку метки или исправление критичного дефекта).

Используя плагины, разработчики могут получить доступ к системе сборки из своей среды разработки (Eclipse 3.02+/Rational Application Developer и Microsoft Visual Studio). Сама по себе идея не нова, но результаты могут быть интересны – теперь количество оправданий от разработчиков, почему нельзя было сделать проверочную сборку, явно уменьшится.

Одним из мотивов для внедрения системы управления сборкой часто становится реализация принципа непрерывной интеграции (Continuous Integration) – создания полностью автоматизированного конвейера из этапов кодирования, сборки, развертывания и тестирования. В этой области Build Forge по потенциалу превосходит даже такие продукты, как Cruise Control или Anthill, для которых этот подход является основополагающим. По сути, речь идет об инфраструктуре автоматизации любых процессов в распределенной среде. Цена минимальной конфигурации IBM Rational Build Forge Express Edition 1,4 млн руб.

***

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

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

Владимир Амелин (VAmelin@aplana.com) – руководитель проектов компании «Аплана» (Москва).

Поделитесь материалом с коллегами и друзьями