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

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

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

      0
      Для введения великолепно; ждем продолжения.

      >> попытаюсь сделать этот вопрос более прозрачным, чем он есть (подозреваю для многих) сейчас

      И многое, и многое ещё :)
        +1
        Интересно, ждём продолжения. :)
          +1
          Будет еще интереснее, если в модели, которую Вы разработали, учитывается не только конфигурационный менеджмент исходного и бинарного кода, но и, например, базы данных, без которой бинарный код работать не будет.
            0
            Учитывается. Пусть не в полной мере, но планируется разработать не очень сложный инструмент для интеграции баз данных. Предполагается что он будет основан на использовании XML представления схемы базы данных, которую использует DBDesigner. Это, согласен, не enterprise уровень, но, тем не менее кое какое решение.
              0
              Отлично, но сразу хотелось бы отметить, что схема — это только половина проблемы. Зачастую поведение приложения определяется не столько схемой, сколько данными, если так можно выразиться, то управляющими данными.
                0
                Никто стандартные инсерты не отменял ;) А еще есть такие понятия как фикстуры, тоже могут в этом деле помочь. Фишка в тот, что всё хранится как исходный код
                  0
                  Парсить инсерты и сравнивать с содержимым БД? Неслабая затея :) А если нужно откатиться до определенной версии, ведь это должно обеспечиваться конфигурационным менеждментом?
                    0
                    ну инсерты — это не так сложно. решение может заключаться в хранении как инсертов, так и delete'ов. вот с апдейтами сложнее.

                    а вообще согласен. интеграция баз данных — это самое проблемное место.
            +1
            Уточню детали из реальной жизни:

            1. Версии сборок. Централизовано назначается номер версии ( 4.28.2625 ) и добавляется во все, что связано с программой. ЭТО интегрируется в систему контроля версий и позволяет решать следующую задачу: «пользователи нашли баг в документации. Номер сборки 4.28.2625. Извлекаем и исправляем» или «у пользователя упала сборка 4.28.2625. Вот крашдамп. Извлекаем, собираем, смотрим»
            2. Справка для программе. Часто с автоматической генерацией скриншотов из сборки. Хранится в виде некоего «исходника» в системе контроля версий, автоматически оттуда собирается в .chm, .pdf, .html и еще много чего и куда.
            3. Установщик. Хорошо если программа детская и под windows — тогда это installshield или wix, исходники в репозитории, установщик собирается после того как собралось все остальное. Хуже когда программа взрослая — драйвера, сервисы, COM-DCOM-Вася-Пупкин-VB-ActiveX. Несколько сборок под разные операционные системы — тут и .pkg, и .dmg и чего только нету
            4. Внутренняя документация :). Тоже живет в несчастной системе контроля версий. Кроме заголовка в .cpp вида "// тут все просто, 50kloc кода документировано на языке с++" часто содержит настройки генерации .doxygen, диаграмы, «vision» документы и прочую муть, свойственную сложным длительным проектам.
              0
              вопрос: встречали ли вы унифицированный подход к менеджменту этого всего добра? возможно кто-то другой занимался этим до меня? почему-то у меня ощущение что от проекта к проекту это всё делается по-разному и причем настолько по-разному, что зачастую концов не сыщешь) это так или не совсем?

              вроде как все вами описанные особенности в своем методе я попытался учесть. если интересно, следите за следующими статьями
                +1
                Встречал конечно. Этим занимаются либо Lead'ы, либо нанятые специалисты из компаний, которые на этом деньга зарабатывают. Свои процессы как правило никто не открывает, потому что это интеллектуальная собственность компаний где внедряется и за нее уплачена зряплата. Компании которые это продают за деньги тоже не открывают по понятным причинам :)

                Тут есть один нюанс. ИМХО ( я могу ошибаться ) «унифицированный подход к менеджменту всего этого добра» нужен не сам по себе ( чтобы круто было ) а для решения конкретных задач. Когда я ЭТО делал, то фокусировался на решении списка задач — «реакция на крашдамп», «корректные скриншоты последней версии для всех 30 языков», «что отдавать локализаторам и что с них спрашивать», «как сделать и поддерживать версию с логотипом для журнала», «как переводить на новый язык», «а как на него переводить инсталятор?» и прочее. Список довольно большой :). Исходя из этого «списка неприятностей» составлялись методики автоматизации, скриптования и централизации. Дабы задачи решались в адекватные сроки и с прогнозируемым качеством.

                В целом, могу сказать на собственно опыте что это долго, дорого и требует очень широкого кругозора и опыта общения с полным циклом разработки ПО. Включая нюансы продаж, техподдержки, марцетинга и прочего. ИМХО актуально для достаточно дорогих и хороших продуктов которые будут продаваться еще очень долго.
                  0
                  Ну я ориентировался в основном на веб-приложения, которые мы разрабатываем/разрабатывали. Попытался как-то обобщить приобретенный опыт. Плюс брал во внимание стандартный набор деятельности, который я уже перечислял: контроль версий, сборки, юнит-тесты, статический анализ кода, генерация документации на основе исходного кода и непрерывная интеграция. По-моему, включение всего этого в область интересов метода конфигурационного менеджмента должно покрыть задачи, возникающие у довольно большого пласта типовых проектов. Предполагаю также что на твердом фундаменте формализованного метода можно построить и более сложный процесс, который учитывает больше нюансов.
                    +1
                    можно но не нужно… работал с конторой где «на твердом фундаменте формализованного метода» было построенно ФСЕ, на курилках только и разговоров было про этот «фундамент», использовалась в основном нецензурная лексика… но зато «со стороны руководства» все выглядело отлично — пипл шуршит, «вот я вижу что процесс идет» и все в таком духе… конторы больше нет… во многом благодаря фундаменту, очень многие ушли с причиной да я за эти-же деньги «там» не буду иметь этого гемороя… я конечно о приземленном а вы о вечном :)
                      0
                      что, там прям куча метрик собиралась и диаграммы строились?) круто! это ж долгожданная сингулярность (то есть рай) менеджера
                        0
                        вроде того, я тебе больше скажу, например, собирался вижн клиенту на основе экспертных оценок консультантов и коэфициентов подсмотренных разработчиком видимо в умной книге по менеджменту — жесть, иногда «почему-то» вижн получался «неправильным» поэтому «самому главному эксперту» приходилось его всегда перепроверять — редкий идиотизм, там много заморочек было.
                  +1
                  лично я не встречал, думаю поиск серебряной пули находится где-то рядом — имхо менеджмент проекта доводить до фанатизЬма не стоит, есть мнение что затраты на менеджмент обратно-пропорциональны скилам его участников, и чрезмерное зацикливание на менеджменте должно стать тревожным звоночком о низких этих самых скилах…
                    0
                    ну в моем случае, как мне кажется, дела обстоят немного по-другому. есть набор деятельностей, которыми занимаются прогеры по ходу разработки. скилы по каждой из деятельностей вполне адекватны. но за счет того, что эти деятельности обычно проводились по отдельности, при их совместном использовании возникает куча проблем, так как они не приспособлены друг к другу. да и «менеджмент» и «конфигурационный менеджмент» — это довольно разные вещи. экстраполирование немного неуместно, хотя признаю — есть кое какие общие черты и недостатки.
                      0
                      да, я рассматривал менеджмент, в контексте данной статьи именно как «прогерский»
                +1
                У PMI есть стандарт Practice Standart for Project Configuration Management. У меня не дошли руки его прочитать, но думаю что 61 страница руководства должна быть очень подробной :)

                Стандарт для членов PMI можно скачать у них на сайте pmi.org, либо отдельно купить там же
                  0
                  Жаль членство стоит денег. Подозреваю этого стандарта в свободном доступе нет?
                  0
                  Когда будет продолжение?
                    +1
                    А как по вашему, насколько актуальна затронутая тема? Тут люди возражают по поводу того, что дескать «нафик нам эти формализованные процессы?» :)
                      +1
                      я считаю тему актуальной. организация разработки порой бывает важней самой разработки.
                        0
                        Пока что не могу сказать конкретно, когда напишутся новые статьи. Дело в том, что не так просто уместить идеи из дипломной работы в нескольких статьях. К тому же еще не до конца продумана структура и формат будущего материала. Но желание поделиться наработками с сообществом довольно велико и это основной движимый фактор. Пока могу сказать одно — нужно чуть подождать. Спасибо вам за интерес.

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

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