Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции PHPCONF 2009 8 октября (Web Architect Workshop Day) с мастер-классом «Метод организации репозитория исходного кода». Для выступления были заблаговременно подготовлены презентация, а также текст доклада. Несмотря на отличную организацию мероприятия, для публичного доступа так и не были выложены материалы докладов, входящих в программу конференции. В качестве компенсации я решил таки опубликовать материал, использованный в моем выступлении. Кроме данной статьи, (которая является логическим продолжением предыдущей), посвященной конфигурационному менеджменту, для публичного обозрения доступны слайды презентации.
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.
Построению такого налаженного процесса вполне могут поспособствовать подходы, используемые в конфигурационном менеджменте, так как это основная дисциплина в определении того, каким образом управляются и контролируются рабочие материалы программного проекта, внесенные в него изменения, а также информация про состояние отдельных задач и всего проекта в целом. Как уже было сказано ранее (в предыдущей статье), в область интересов конфигурационного менеджмента попадают (далее каждый пункт будет рассмотрен отдельно):
Контроль версий является основным процессом управления конфигурациями. Отсутствие необходимости использовать контроль версий при разработке, практически, равно нулю. Большинство разработчиков знакомы с такими системами контроля версий (СКВ) как CVS, Subversion или VSS. Также популярность приобретают распределенные системы контроля версий: git, mercurial, bazaar. Упомянутые системы контроля версий оказывают большое влияние на формирование понятий об управлении конфигурациями у разработчиков. По этой причине обычно разработчики не задумываются о продуманной организации репозитория. Простейшее и единственное решение предлагает СКВ subversion. Это решение используется чаще всего: деление на trunk, branches и tags. Хоть в большинстве репозиториев subversion можно увидеть данную иерархию директорий, нельзя сказать, что они всегда одинаково активно используются: в лучшем случае в директории branches можно увидеть несколько директорий веток параллельной разработки. Опаску разработчиков при создании разветвленной структуры директорий репозитория можно понять – это зачастую сулит много проблем, связанных со слиянием изменений между ветками. Но при командной разработке приложений, имеющих несколько версий или работающих на разных платформах избежать слияний практически невозможно. Зато можно минимизировать их количество, регламентируя ситуации, при которых можно проводить слияния, а при которых – нет. Но для определения такого регламента нужно доскональное понимание явлений, связанных с ведением репозитория.
Другим важным процессом управления конфигурациями является управление сборками. Управление сборками — это автоматизация действий относительно:
Хоть юнит-тестирование и нельзя в полной мере причислить к процессам конфигурационного менеджмента, оно обладает достаточно важными свойствами, которые определяют особую роль юнит-тестирования в управлении конфигурациями. Так, использование юнит-тестирования в программных проектах, написанных на интерпретируемых языках программирования определяет кроме необходимости управления сборками также и нужду в более основательном подходе к управлению конфигурациями. Во-первых, юнит-тестирование появляется там, где предполагается проведение рефакторинга. Во-вторых, при принятии решения о применении юнит-тестов обычно принимается во внимание архитектурная и логическая целостность проекта, которую нужно поддерживать на достаточном уровне. Это означает, что принятие решения об использовании юнит-тестирования автоматически подразумевает введение ряда дополнительных процессов (а также расходов) связанных с организацией разработки, хоть это может быть не так очевидно.
Кроме поддержки архитектурной и логической целостности в больших проектах существует необходимость выявления синтаксических ошибок на ранних стадиях разработки. Кроме выявления синтаксических и логических ошибок в исходном коде часто необходимо в автоматическом режиме проводить верификацию на соответствие code conventions. Статический анализ кода более актуален для интерпретируемых языков, так как в компилируемых языках большинство ошибок выявляется на стадии компиляции. Иногда статический анализ может производиться для сбора метрик исходного кода и составления соответствующей отчетности. Примером библиотек, используемых для статического анализа исходного кода являются библиотеки, представленные в таблице:
Генерация документации на основе исходного кода и комментариев в стиле javaDoc, phpDoc итп актуальна чаще всего для проектов с активным использованием исходного кода: библиотек, повторно используемых компонентов, фреймворков и др. Инструменты, наиболее часто использующиеся при генерации документации представлены в таблице:
Непрерывная интеграция (англ. Continuous Integration, CI) – это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для наиболее раннего выявления и решения интеграционных проблем. В обычном проекте (не использующем практику непрерывной интеграции), где разработчики работают независимо над каждой частью приложения, стадия интеграции является заключительной. Как справедливо замечено в лаконичной википедийной статье, описывающей CI, непрерывная интеграция не может быть применена к любому проекту. Для внедрения практики continuous integration проект должен удовлетворять ряду требований:
Важным вопросом, занимающим отдельное место при рассмотрении задач управления конфигурациями, является интеграция баз данных. В большинстве случаев, базы данных являются неотъемлемой частью приложений. Разработка с помощью agile-методологий предусматривает не только постоянное совершенствование программного кода, но и структуры базы данных, а также ее функциональности. Причем обычно это происходит параллельно – вместе с изменением программного кода вносятся изменения в типы полей, названия полей, функций, триггеров, индексов базы данных. Эволюция базы данных в ходе жизненного цикла проекта напоминает эволюцию программного кода, имея практически те же особенности при рассмотрении базы данных как объекта конфигурационного менеджмента. Хотя конфигурационный менеджмент баз данных и контроль версий баз данных имеют существенные отличия по сравнению с конфигурационным менеджментом программного кода, это является неотъемлемой частью ведения проекта и находит свое отражение в процессе интеграции баз данных. SQL-приложение часто можно рассматривать как приложение в приложении и выделять в отдельный проект, подлежащий версионированию. Выделяют два типа идентификационных элементов, использующихся при версионировании баз данных: DML (Database Manipulation Language) и DDL (Database Definition Language). DML – это подмножество SQL, использующееся для манипуляции данными: выборки, вставки, удаления, апдейты (CRUD-операции). DDL – это также подмножество SQL, но использующееся для описания структуры БД: создание таблиц, индексов, триггеров, ограничений целостности и т.д. При организации интеграции базы данных рекомендуется разделять DML и DDL-артефакты и заниматься их управлением отдельно.
Тенденция использования систем (системы контроля постановки задач) указывает на всё более частые попытки таких систем интегрировать в себе средства управления программным проектом. Часто это происходит не прямо, а косвенно – посредством выпуска различных плагинов (интеграция с системами контроля версий, отображение javaDoc, phpDoc или Doxygen документации итд). Но даже в базовом наборе функциональности касающемся CRM (change request management, контроль запросов на изменения) существуют элементы, подлежащие улучшению. Таким элементом может быть, к примеру, именование версий. Но от использования стандартизированных имен версий удерживает необходимость использования определенных соглашений не только в issue-tracking системе, но и при контроле версий, а также других процессах УК.
Подход к разработке программного обеспечения, предполагающий использование гибкой методологии обладает рядом отличительных свойств, которые наиболее ощутимо влияют на организацию управления конфигурациями. Такими свойствами являются:
В данной статье без углубления в детали рассмотрены процессы, входящие в состав управления конфигурациями. Для обеспечения каждого процесса используется отдельный инструмент, который может быть выбран из множества альтернатив. Было отмечено, что в силу разнородности самих инструментов, а также различию задач, которые они решают, сложно добиться их максимальной интеграции и эффективности. Следующая статья будет именно об этом – как путем введения дополнительной формализации (организации репозитория исходного кода) добиться более эффективного использования инструментов, используемых при УК.
Продолжение следует
Ссылки:
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.
- Во-первых, каждый инструмент используется для решения ряда специфических задач.
- Во-вторых, решение задачи предполагает предшествующее использованию инструмента удовлетворение набора требований, без которых инструмент не будет эффективен или не будет работать
- В-третьих, часто набор требований, выдвигаемый множеством используемых инструментов, удовлетворен не полностью. Кроме того, требования разных инструментов могут вступать между собой в противоречия. Всё это приводит к тому, что эффективность использования таких вспомогательных средств уменьшается.
Построению такого налаженного процесса вполне могут поспособствовать подходы, используемые в конфигурационном менеджменте, так как это основная дисциплина в определении того, каким образом управляются и контролируются рабочие материалы программного проекта, внесенные в него изменения, а также информация про состояние отдельных задач и всего проекта в целом. Как уже было сказано ранее (в предыдущей статье), в область интересов конфигурационного менеджмента попадают (далее каждый пункт будет рассмотрен отдельно):
- Контроль версий (version control)
- Билд-менеджмент (build management)
- Юнит-тестирование (unit-testing)
- Статический анализ кода (static analysis)
- Генерация документации (phpDoc)
- Непрерывная интеграция (continuous integration)
- Управление зависимостями (dependency management)
- Интеграция баз данных
- Баг-трекинг (bug-tracking) и контроль постановки задач (issue-tracking)
- Управлением выпуском (release management)
- Наладкой поставок (delivery)
- Организацией налаженных процессов разработки
- Согласованием способа взаимодействия разных частей программного проекта
Контроль версий
Контроль версий является основным процессом управления конфигурациями. Отсутствие необходимости использовать контроль версий при разработке, практически, равно нулю. Большинство разработчиков знакомы с такими системами контроля версий (СКВ) как CVS, Subversion или VSS. Также популярность приобретают распределенные системы контроля версий: git, mercurial, bazaar. Упомянутые системы контроля версий оказывают большое влияние на формирование понятий об управлении конфигурациями у разработчиков. По этой причине обычно разработчики не задумываются о продуманной организации репозитория. Простейшее и единственное решение предлагает СКВ subversion. Это решение используется чаще всего: деление на trunk, branches и tags. Хоть в большинстве репозиториев subversion можно увидеть данную иерархию директорий, нельзя сказать, что они всегда одинаково активно используются: в лучшем случае в директории branches можно увидеть несколько директорий веток параллельной разработки. Опаску разработчиков при создании разветвленной структуры директорий репозитория можно понять – это зачастую сулит много проблем, связанных со слиянием изменений между ветками. Но при командной разработке приложений, имеющих несколько версий или работающих на разных платформах избежать слияний практически невозможно. Зато можно минимизировать их количество, регламентируя ситуации, при которых можно проводить слияния, а при которых – нет. Но для определения такого регламента нужно доскональное понимание явлений, связанных с ведением репозитория.
Управление сборками
Другим важным процессом управления конфигурациями является управление сборками. Управление сборками — это автоматизация действий относительно:
- Компиляции исходного кода
- Развертывания (deployment) приложения
- Запуска юнит-тестов
- Инициализации базы-данных
- Групповые операции над файлами
- Компиляция
- Развертывание
- Взаимодействие с системами контроля версий
Юнит-тестирование
Хоть юнит-тестирование и нельзя в полной мере причислить к процессам конфигурационного менеджмента, оно обладает достаточно важными свойствами, которые определяют особую роль юнит-тестирования в управлении конфигурациями. Так, использование юнит-тестирования в программных проектах, написанных на интерпретируемых языках программирования определяет кроме необходимости управления сборками также и нужду в более основательном подходе к управлению конфигурациями. Во-первых, юнит-тестирование появляется там, где предполагается проведение рефакторинга. Во-вторых, при принятии решения о применении юнит-тестов обычно принимается во внимание архитектурная и логическая целостность проекта, которую нужно поддерживать на достаточном уровне. Это означает, что принятие решения об использовании юнит-тестирования автоматически подразумевает введение ряда дополнительных процессов (а также расходов) связанных с организацией разработки, хоть это может быть не так очевидно.
Статический анализ кода
Кроме поддержки архитектурной и логической целостности в больших проектах существует необходимость выявления синтаксических ошибок на ранних стадиях разработки. Кроме выявления синтаксических и логических ошибок в исходном коде часто необходимо в автоматическом режиме проводить верификацию на соответствие 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 проект должен удовлетворять ряду требований:
- Исходный код и всё необходимое для сборки сохраняется либо в репозитории исходного кода, либо в легкодоступном месте.
- Операции копирования из репозитория, сборки и тестирования всего проекта автоматизированы и легко вызываются из внешней программы.
Интеграция баз данных
Важным вопросом, занимающим отдельное место при рассмотрении задач управления конфигурациями, является интеграция баз данных. В большинстве случаев, базы данных являются неотъемлемой частью приложений. Разработка с помощью 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
Подход к разработке программного обеспечения, предполагающий использование гибкой методологии обладает рядом отличительных свойств, которые наиболее ощутимо влияют на организацию управления конфигурациями. Такими свойствами являются:
- изменяющиеся требования
- итеративность
- непрерывная поставка.
Заключение
В данной статье без углубления в детали рассмотрены процессы, входящие в состав управления конфигурациями. Для обеспечения каждого процесса используется отдельный инструмент, который может быть выбран из множества альтернатив. Было отмечено, что в силу разнородности самих инструментов, а также различию задач, которые они решают, сложно добиться их максимальной интеграции и эффективности. Следующая статья будет именно об этом – как путем введения дополнительной формализации (организации репозитория исходного кода) добиться более эффективного использования инструментов, используемых при УК.
Продолжение следует
Ссылки:
- Issue tracking system (wiki)
- Continuous integration (wiki)
- Version Control for Multiple Agile Teams
- Continuous deployment in 5 easy steps
- Инструмент для сборки метрик svn-репозитория
- Code coverage analysis
- Метрики кода и их практическая реализация в IBM Rational ClearCase
- SLOCCount — инструмент для подсчета количества строк кода
- Continuous Builds with CruiseControl, Ant and PHPUnit — пример организации простой платформы для управления конфигурациями
- Мой отчет о PHPCONF 2009
