Pull to refresh

Конфигурационный менеджмент (часть 2, обзор инструментов)

Reading time9 min
Views6.7K
Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции PHPCONF 2009 8 октября (Web Architect Workshop Day) с мастер-классом «Метод организации репозитория исходного кода». Для выступления были заблаговременно подготовлены презентация, а также текст доклада. Несмотря на отличную организацию мероприятия, для публичного доступа так и не были выложены материалы докладов, входящих в программу конференции. В качестве компенсации я решил таки опубликовать материал, использованный в моем выступлении. Кроме данной статьи, (которая является логическим продолжением предыдущей), посвященной конфигурационному менеджменту, для публичного обозрения доступны слайды презентации.
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.
  • Во-первых, каждый инструмент используется для решения ряда специфических задач.
  • Во-вторых, решение задачи предполагает предшествующее использованию инструмента удовлетворение набора требований, без которых инструмент не будет эффективен или не будет работать
  • В-третьих, часто набор требований, выдвигаемый множеством используемых инструментов, удовлетворен не полностью. Кроме того, требования разных инструментов могут вступать между собой в противоречия. Всё это приводит к тому, что эффективность использования таких вспомогательных средств уменьшается.
Здесь в качестве инструментов выступают любые средства используемые программистом при разработке: будь-то IDE, фреймворк, система контроля версий или отдельная технология. Каждый разработчик явно или неявно сталкивается с проблемой менеджмента используемых им инструментов. Чаще всего решение подобного рода проблем либо происходит на интуитивном уровне, либо происходит вполне сознательный выбор первичного инструмента, на котором строится большая часть процесса разработки. Мало у кого получается объединить большинство используемых инструментов в единую платформу, тогда как это могло бы послужить построению налаженного процесса разработки.

Построению такого налаженного процесса вполне могут поспособствовать подходы, используемые в конфигурационном менеджменте, так как это основная дисциплина в определении того, каким образом управляются и контролируются рабочие материалы программного проекта, внесенные в него изменения, а также информация про состояние отдельных задач и всего проекта в целом. Как уже было сказано ранее (в предыдущей статье), в область интересов конфигурационного менеджмента попадают (далее каждый пункт будет рассмотрен отдельно):
  1. Контроль версий (version control)
  2. Билд-менеджмент (build management)
  3. Юнит-тестирование (unit-testing)
  4. Статический анализ кода (static analysis)
  5. Генерация документации (phpDoc)
  6. Непрерывная интеграция (continuous integration)
  7. Управление зависимостями (dependency management)
  8. Интеграция баз данных
  9. Баг-трекинг (bug-tracking) и контроль постановки задач (issue-tracking)
Также из неупомянутого ранее можно отметить то, чем же собственно управление конфигурациями занимается:
  • Управлением выпуском (release management)
  • Наладкой поставок (delivery)
  • Организацией налаженных процессов разработки
  • Согласованием способа взаимодействия разных частей программного проекта
Нужно отметить то, что нужно стараться четко разграничивать процессы УК (контроль версий, билд-менеджмент итд) и задачи УК (управление выпуском, наладка поставок итд). Для выявления существенных особенностей процессов УК, нужно рассмотреть каждый такой процесс (а также его связь с управлением конфигурациями) отдельно.

Контроль версий


Контроль версий является основным процессом управления конфигурациями. Отсутствие необходимости использовать контроль версий при разработке, практически, равно нулю. Большинство разработчиков знакомы с такими системами контроля версий (СКВ) как CVS, Subversion или VSS. Также популярность приобретают распределенные системы контроля версий: git, mercurial, bazaar. Упомянутые системы контроля версий оказывают большое влияние на формирование понятий об управлении конфигурациями у разработчиков. По этой причине обычно разработчики не задумываются о продуманной организации репозитория. Простейшее и единственное решение предлагает СКВ subversion. Это решение используется чаще всего: деление на trunk, branches и tags. Хоть в большинстве репозиториев subversion можно увидеть данную иерархию директорий, нельзя сказать, что они всегда одинаково активно используются: в лучшем случае в директории branches можно увидеть несколько директорий веток параллельной разработки. Опаску разработчиков при создании разветвленной структуры директорий репозитория можно понять – это зачастую сулит много проблем, связанных со слиянием изменений между ветками. Но при командной разработке приложений, имеющих несколько версий или работающих на разных платформах избежать слияний практически невозможно. Зато можно минимизировать их количество, регламентируя ситуации, при которых можно проводить слияния, а при которых – нет. Но для определения такого регламента нужно доскональное понимание явлений, связанных с ведением репозитория.

Управление сборками


Другим важным процессом управления конфигурациями является управление сборками. Управление сборками — это автоматизация действий относительно:
  • Компиляции исходного кода
  • Развертывания (deployment) приложения
  • Запуска юнит-тестов
  • Инициализации базы-данных
Нужно заметить, что инструменты управления сборками характеризуются тем, что файлы сборок обычно используют XML-синтаксис (Ant, Nant, Maven, MSBuild, Phing), хотя существуют и исключения (make, nmake, cmake, rake). Обычно инструменты управления сборками обладают специфическими для процесса сборки командами, такими как:
  • Групповые операции над файлами
  • Компиляция
  • Развертывание
  • Взаимодействие с системами контроля версий
Эти и другие свойства инструментов управления сборками позволяют достигать простой интеграции с другими инструментами, использующимися при разработке; инструменты управления сборками выступают в качестве связующего звена для большинства процессов, подлежащих автоматизации при управлении конфигурациями.

Юнит-тестирование


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

Статический анализ кода


Кроме поддержки архитектурной и логической целостности в больших проектах существует необходимость выявления синтаксических ошибок на ранних стадиях разработки. Кроме выявления синтаксических и логических ошибок в исходном коде часто необходимо в автоматическом режиме проводить верификацию на соответствие code conventions. Статический анализ кода более актуален для интерпретируемых языков, так как в компилируемых языках большинство ошибок выявляется на стадии компиляции. Иногда статический анализ может производиться для сбора метрик исходного кода и составления соответствующей отчетности. Примером библиотек, используемых для статического анализа исходного кода являются библиотеки, представленные в таблице:
Язык программирования Инструмент
Java PMD
FindBugs
C/C++ Cppcheck
Lint
C# FxCop
StyleCop
ReSharper
PHP PHP_CodeSniffer
PHP-sat
PHP_Depend
Pixy
Python PyChecker
PyLint
PyFlakes
Ruby Reek
Roodi
Rufus
Flay
Flog
Инструменты, независимые от языка программирования RATS
Yasca


Генерация документации


Генерация документации на основе исходного кода и комментариев в стиле javaDoc, phpDoc итп актуальна чаще всего для проектов с активным использованием исходного кода: библиотек, повторно используемых компонентов, фреймворков и др. Инструменты, наиболее часто использующиеся при генерации документации представлены в таблице:
Ориентированные на конкретный язык программирования PHP phpDocumentor
Java JavaDoc
C++ CppDoc
Python pyDoc
Ruby RDoc
Deplhi DelphiCodeToDoc
C# NDoc
Не ориентированные на использование конкретного языка программирования Doxygen
ROBODoc
TwinText

Непрерывная интеграция


Непрерывная интеграция (англ. Continuous Integration, CI) – это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для наиболее раннего выявления и решения интеграционных проблем. В обычном проекте (не использующем практику непрерывной интеграции), где разработчики работают независимо над каждой частью приложения, стадия интеграции является заключительной. Как справедливо замечено в лаконичной википедийной статье, описывающей CI, непрерывная интеграция не может быть применена к любому проекту. Для внедрения практики continuous integration проект должен удовлетворять ряду требований:
  1. Исходный код и всё необходимое для сборки сохраняется либо в репозитории исходного кода, либо в легкодоступном месте.
  2. Операции копирования из репозитория, сборки и тестирования всего проекта автоматизированы и легко вызываются из внешней программы.
Обычно инструменты непрерывной интеграции настроены на инициирование сборки по наступлению события обновления репозитория. При наличии этапа развертывания, включенного в процесс сборки, непрерывная интеграция может быть приспособлена к обеспечению команды тестировщиков работающей и готовой к тестированию копии приложения. При разработке могут использоваться такие инструменты непрерывной интеграции как: CruiseControl, phpUnderControl, Xinc, CruiseControl.rb, TeamCity, Apache Continuum, Hudson, Parabuild, Atlassian Bamboo и др.

Интеграция баз данных


Важным вопросом, занимающим отдельное место при рассмотрении задач управления конфигурациями, является интеграция баз данных. В большинстве случаев, базы данных являются неотъемлемой частью приложений. Разработка с помощью agile-методологий предусматривает не только постоянное совершенствование программного кода, но и структуры базы данных, а также ее функциональности. Причем обычно это происходит параллельно – вместе с изменением программного кода вносятся изменения в типы полей, названия полей, функций, триггеров, индексов базы данных. Эволюция базы данных в ходе жизненного цикла проекта напоминает эволюцию программного кода, имея практически те же особенности при рассмотрении базы данных как объекта конфигурационного менеджмента. Хотя конфигурационный менеджмент баз данных и контроль версий баз данных имеют существенные отличия по сравнению с конфигурационным менеджментом программного кода, это является неотъемлемой частью ведения проекта и находит свое отражение в процессе интеграции баз данных. SQL-приложение часто можно рассматривать как приложение в приложении и выделять в отдельный проект, подлежащий версионированию. Выделяют два типа идентификационных элементов, использующихся при версионировании баз данных: DML (Database Manipulation Language) и DDL (Database Definition Language). DML – это подмножество SQL, использующееся для манипуляции данными: выборки, вставки, удаления, апдейты (CRUD-операции). DDL – это также подмножество SQL, но использующееся для описания структуры БД: создание таблиц, индексов, триггеров, ограничений целостности и т.д. При организации интеграции базы данных рекомендуется разделять DML и DDL-артефакты и заниматься их управлением отдельно.

Issue tracking


Тенденция использования систем (системы контроля постановки задач) указывает на всё более частые попытки таких систем интегрировать в себе средства управления программным проектом. Часто это происходит не прямо, а косвенно – посредством выпуска различных плагинов (интеграция с системами контроля версий, отображение javaDoc, phpDoc или Doxygen документации итд). Но даже в базовом наборе функциональности касающемся CRM (change request management, контроль запросов на изменения) существуют элементы, подлежащие улучшению. Таким элементом может быть, к примеру, именование версий. Но от использования стандартизированных имен версий удерживает необходимость использования определенных соглашений не только в issue-tracking системе, но и при контроле версий, а также других процессах УК.

Agile


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

Заключение


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

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

Ссылки:
  1. Issue tracking system (wiki)
  2. Continuous integration (wiki)
  3. Version Control for Multiple Agile Teams
  4. Continuous deployment in 5 easy steps
  5. Инструмент для сборки метрик svn-репозитория
  6. Code coverage analysis
  7. Метрики кода и их практическая реализация в IBM Rational ClearCase
  8. SLOCCount — инструмент для подсчета количества строк кода
  9. Continuous Builds with CruiseControl, Ant and PHPUnit — пример организации простой платформы для управления конфигурациями
  10. Мой отчет о PHPCONF 2009

Tags:
Hubs:
Total votes 24: ↑20 and ↓4+16
Comments25

Articles