Конфигурационный менеджмент (часть1, вступительная)

Как разрабатывать большое ПО? Ни для кого не секрет, что потребность в разработке больших и сложных программных продуктов была всегда и также всегда была независимой от уровня технологий, существующих на тот или иной момент времени. Но исследуя и анализируя существующие подходы к девелопменту, я так и не смог ответить на самые простые вопросы, связанные с «правильной» разработкой качественных программ. Одним из простейших вопросов, который я перед собой ставил, был вопрос о том, как назначать номера версий выпускаемому программному продукту. Наверняка многие согласятся, что это касается не только больших корпоративных приложений, но и самых простых приложений, которые выходят из под пера начинающих программистов, школьников и студентов. Смысл назначения версий возникает тогда, когда программа перестает быть экспериментом и начинает делать что-то полезное. Но стоит заметить, что даже экспериментальным версиям программ есть смысл назначать уникальный идентификатор. Изменение номеров версий отображает последовательный подход к разработке и, с одной стороны, представляет собой соответствие выдвигаемым к разрабатываемой программе требованиям, а с другой стороны – связь с предыдущими версиями в виде общей базовой функциональности или базы исходного кода (source codebase). Мы уже не задаем вопрос о том, как разрабатывать большое ПО, а пытаемся представить себе то, как назначать версии своим программам. Да, но какая между этими вопросами связь? На самом деле очень большая.

Перед началом разработки какого либо программного проекта должно быть решено довольно много вопросов: где взять финансирование, сколько людей будет работать над проектом, какие установить сроки, какие есть риски и много-много других. Но это с менеджерской позиции. С позиции программиста решаются вопросы другого рода: проектирование архитектуры, базы данных, рисование UML-диаграмм и прочее. Но это в теории – потратить день, чтобы за 5 минут долететь. Если считать все вышеуказанные шаги этапом «0» в разработке проекта, то на практике программный проект начинается с этапа номер «1» – с разработки. Пусть это не совсем правильно, но что делать тогда, когда ни на один из вопросов, которые ставятся перед началом разработки ответить с большой степенью вероятности нельзя? Даже если такие ответы есть, в том или ином виде любой программный продукт претерпевает эволюционные изменения — требования имеют тенденцию меняться. Таким образом, любой программный проект подвергается трудно формализуемым влияниям, которые своим результатом имеют разные версии продукта, от этого никуда не деться.

Гибкие методологии (agile methodologies) известны тем, что пытаются организационными мерами решить подобного рода проблемы, и это, надо сказать получается довольно успешно. Но это организационный уровень. Программистский уровень предполагает немного другие задачи и проблемы. Нельзя сказать, что они не решаются совсем, но недостаток таких решений, на мой взгляд, заключается в том, что всеми они решаются по-разному. Даже одними и теми же людьми, но для разных проектов одни и те же задачи решаются по-разному. Для того, чтобы понять что я имею в виду и для того, чтобы выделить суть подходов к гибкой разработке с точки зрения программиста я перечислю подходы, которые обычно используются:

1. Контроль версий (version control)
2. Автоматизированные сборки (build management)
3. Юнит-тестирование (unit-testing)
4. Статический анализ кода (static source code analysis)
5. Генерация документации на основе исходного кода (javaDoc, phpDoc, Doxygen итп)
6. Непрерывная интеграция (continuous integration)

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

Как оказалось, существует отдельная дисциплина инженерии программного обеспечения, которая занимается подобного рода организационными задачами без привязки к методологиям – это конфигурационный менеджмент (configuration management). Управление конфигурациями является основной дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы программного проекта, внесенные в него изменения, а также информация про состояние отдельных задач и всего проекта в целом. Успех проекта в большой мере зависит от того, насколько налажен процесс управления конфигурациями и это может как спасти проект, так и похоронить его в том случае, если управление конфигурациями работает плохо.

Глоссарий IEEE 610 описывает управление конфигурациями как дисциплину применения технических и административных указаний (инструкций) и контроля (наблюдения) для: идентификации и документирования функциональных и физических характеристик элементов конфигураций; контроля (управления) над изменениями этих характеристик; записи (сохранения) и ведения отчетности по обработке изменений и статуса их реализации; проверки (верификации) соответствия выдвинутым требованиям.

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

• Subversion; CVS; Git; Mercurial; Bazaar; Microsoft Visual SourceSafe; ClearCase; Perforce
• Ant; Nant; Maven; Phing; make; nmake; Cmake; MSBuild; Rake
• JUnit; NUnit; CPPUnit; DUnit; PHPUnit; PyUnit; Test::Unit; vbUnit; JsUnit
• PMD; FxCop; PHP_CodeSniffer; PyChecker, lint
• JavaDoc; phpDocumentor; CppDoc; RDoc; PyDoc; NDoc; Doxygen
• CruiseControl; CruiseControl.NET; TeamCity; xinc; Atlassian Bamboo; Hudson
• Jira, Trac, Mantis, Bugzilla, TrackStudio

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

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

Для того, чтобы подогреть интерес к последующим статьям, расскажу немного о сути метода. Так как управление конфигурациями базируется в основном на ведении репозитория исходного кода, вполне логично было бы предположить, что для того, чтобы согласовать работу всех инструментов управления конфигурациями, нужно формализовать правила ведения репозитория. Это должно быть сделано в таком виде, чтобы принятые соглашения могли использоваться в любом из составных элементов платформы управления конфигурациями – в инструментах сборок, инструментах непрерывной интеграции, и, конечно же, людьми. Таким образом, репозиторий структурируется (каждой директории репозитория соответствует определенный класс содержимого, который может в этой директории находиться), а также определяются шаблоны именования директорий. Одним из шаблонов директорий и есть шаблон вида х.х.х, где х – это число. Если более точно, то шаблон описывается регулярным выражением вида \d+\.(\d+|x)\.(\d+|x)(_.*)? . Такой шаблон соответствует наиболее распространенной системе именования сборок и релизов, к которой все привыкли (примеры: 1.0.2, 2.3.5, 3.10.23). Отличие использования данного подхода к именованию в моем методе заключается в том, что зависимости изменений каждой цифры в системе именования от некоторого момента времени описываются формально.

Продолжение следует

Ссылки:

1. svnbook.red-bean.com — О Subversion
2. martinfowler.com/articles/continuousIntegration.html — что такое непрерывная интеграция
3. www.swebok.org — Guide to the Software Engineering Body of Knowledge. Книга о программной инженерии, одна из глав которой посвящена конфигурационному менеджменту. Свободна для скачивания.
4. www.cmcrossroads.com — сообщество, которое ориентировано на обсуждение вопросов, связанных с конфигурационным менеджментом.