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

    Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции 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

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 25

      +4
      Спасибо за продолжение темы SCM, радует, что она по-прежнему интересна прогрессивной общественности :)
      Пользуясь случаем, пиарю свой цикл статей, где даются общие основы CM:

      habrahabr.ru/blogs/pm/67751/ — Общее введение
      habrahabr.ru/blogs/pm/67839/ — Конфигурации и baselines
      habrahabr.ru/blogs/pm/68357/ — Багтрекинг
      habrahabr.ru/blogs/pm/68932/ — Контроль версий
      habrahabr.ru/blogs/pm/69666/ — Метрики и документация
      habrahabr.ru/blogs/pm/72370/ — Распределенный контроль версий

      Думаю, оба цикла статей неплохо дополнят друг друга.
        +2
        Вот техническое описание CI для PHP.
          +1
          Читал, хорошая заметка, спасибо.
        –2
        Много текста, ни о чем. Прописные истины алитые соусом наукообразия.
          0
          А что бы вы хотели чтобы было в подобного рода статье?

          Между прочим, я рад что для вас всё изложенное просто и очевидно, так как, подозреваю, что не все могут этим похвастаться. Чтобы не оставлять вас абсолютно разочарованным после прочтения, предлагаю ознакомиться с диаграммой: bit.ly/34yQZx. Если у вас получится разобраться, и, более того, вндерить у себя в проекте, то я вас смогу искренне поздравить как состоявшегося scm-гуру. Эта диаграмма — конечный пункт моих попыток описать (это одновременно еще и содержание следующих статей) что такое scm и как можно улучшить существующее положение вещей.
            0
            А вот эта диаграмма — хорошо, даже очень хорошо. Учитывает все возможные случаи. Для поддержки проекта и последущей интеграции и поддержки.
            Правда, имхо, сложнова-то выглядит. И это же еще не все. Надо же еще установить правила, не тольк как разбивать на ревизии, но и как и когда внисить изменения в транк. Иначе это похоже на паралельную разработку множества версий 1, 2, 3 когда-то имевшие общих предков. Версии должны заканчиватся, если появилась версия 2, то в этом момент разраотка версии 1 — прекращается и там исправляются только баги — все.
              0
              То что вы описали — учитывается. Просто на диаграмме это не изображено. Диаграмма — самый сложный случай, когда все таки нужно поддерживать несколько версий. Банальный пример — open-source библиотеки и фреймворки. Например CakePHP работает как под PHP4, так и под PHP5 — нужно поддерживать обе версии. Плюс вышел PHP5.3 — вполне логично начать экспериментальную разработку с поддержкой новой версии. Итого — как минимум 3 параллельных ветки, ориентированных только на платформу. А ведь еще могут быть вариации самого фреймворка. Так что случаи с окончанием разработки в ветке версии после ее окончания — это не единственный случай, хотя и очень распространенный.

              Не хотелось бы обсуждать диаграмму, так как я надеюсь что все таки доберусь до написания следующих статей где расскажу про всё это отдельно.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Вы не поверите, но суть в этом собственно и была — поверхностно описать процессы, входящие в область интересов управления конфигурациями
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Спасибо, исправил
            0
            ребята. подскажите пожалуйста где можно почитать о версионировании баз данных?
            0
            Issue Tracking неправильно перевели. Сами же дали ссылку на википедию. А почитать забыли.
            Если говорить о иерархии то Artifact Tracking -> Issue Tracking -> Bug Tracking. Баг трекер — частный случай Issue tracker.
              0
              «контроль постановки задач» — это неправильно? буду рад если вы приведете пример более употребляемого словосочетания. искал искал — не нашел

              ну и вроде как я не отождествляю bug tracking и issue tracking, а наоборот — разграничиваю. кстати, по тем же причинам, на которые вы указали: баг трекер — частный случай
                0
                система отслеживания дефектов.
                  0
                  я имел в виду issue tracking. как насчет присутствия enhancement в issue tracking system, в этом случае она все еще «система отслеживания дефектов»?
                  употребление «баг-трекер» для описания bug-tracker'ов мне кажется вполне допустимым :)
                    0
                    Система отслеживания проблем | инцидентов | дефектов | запросов. Нужное подчеркнуть. Самое главное из всех слов «отслеживания», все остальное тонкости.
                      0
                      Вообще, говоря о «контроле постановки задач», я имею в виду не конкретную систему(-ы), а деятельность (или процесс).
                        0
                        Я понимаю, что вы имеете ввиду. Но еще раз акцентирую внимание, что системы нацелены на отслеживание (можно сказать сопровождение по жизненому циклу) неких артефактов. А есть ли в этом цикле процесс постановки или нет — это уже дело десятое.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое