Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года - интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт - в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле - software configuration management.

А потом увидел статью от камрада altern , в которой он начал рассказывать про СМ. Речь у него пошла несколько в другом ключе - о конкретных инструментах и именовании конфигураций. Поэтому, списавшись с ним, чтобы не пересекаться по тематике наших статей, решил написать об основах того, что называется управлением конфигурацией программных средств.

Сейчас у меня уже написан материал примерно на 50 тысяч знаков - это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.

Задача - дать обзор того, чем же вообще является CM, какие задачи он решает и какие техники при этом используются. Речь не будет идти о конкретных системах контроля версий или вообще инструментах - этого добра навалом в сети. Задача - показать универсальные для всех инструментов основы.

Итак, поехали.

Что такое CM и зачем он нужен

Управление конфигурацией

Для начала определимся, что такое configuration , ведь это слово выведено в заголовок. Конфигурация – это совокупность версий рабочих продуктов. Ключевые слова – «версий продуктов».

В любом проекте есть рабочие продукты – это может быть маркетинговая документация, требования к конечному продукту, исходные коды, тесты, вспомогательные инструменты. Что считать рабочим продуктом, зависит от проекта (определение будет дано в следующей заметке). Далее, каждый продукт изменяется во времени (в этом ведь смысл разработки), и эти изменения надо как-то учитывать – кто, когда, что именно внёс и зачем он это сделал. Иными словами, учитывать, как появлялись версии продуктов.

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

Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.

В англоязычной литературе используется термин Software Configuration Management , сокращенно SCM . Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM (читается: «сиэм»).

Схема 1. Элементы, их версии и срезы-конфигурации.

CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.

Замечу, что Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. Кстати, на втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.

Так в чем же заключается такая ценность CM?

Направления ответственности CM

Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется. Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM. Понадобились метрики по изменениям или документированные политики – ну, вы поняли, к кому обратиться.

Итак, в первую очередь, CM отвечает за идентификацию рабочих продуктов, т.е. отвечает за определение того, что же будет в дальнейшем контролироваться. В следующей заметке будет подробнее про это рассказано.

Продукты выделили, дальше команда начинает работу. По ходу работы нужно периодически стабилизировать полученные результаты, подводить некоторую черту под наработками, а также определять тот базис, на основе которого будет идти разработка. Это всё также входит в сферу деятельности CM’а.

Кроме того, CM отвечает за то, что в общем случае называется отслеживанием запросов на изменения. Большинству эта область известна как системы отслеживания ошибок. Ведь никакие изменения не должны проходить спонтанно – каждое из них нужно регистрировать и затем правильным образом назначать и отслеживать – вплоть до попадание в конечный продукт. Вот тут опять остается крайним CM. Изменения в продукты вносим, надо их отслеживать – начинает работать контроль версий. Ничто не будет потеряно – CM на страже.

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

Ну и, как всегда, «нельзя контролировать то, что нельзя измерить» - (с) Де Марко. Метрики – о них тоже будет сказано пару слов. Где измерения – там и формализация. Другими словами, всё, что связано с CM, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.

Итак, каковы задачи управления конфигурацией?

идентификация рабочих продуктов;
стабилизация результатов работы и определение базы для дальнейшей работы;
отслеживание запросов на изменение;
контроль версий;
обеспечение параллельности разработки;
сбор метрик и формализация применяемых методов.

Кому интересно прочитать ещё немного теории и проникнуться терминами и формальными описаниями области ответственности – вам к стандартам CMM/CMMI (см. ссылки в конце), там это рассматривается много и плодотворно. Правда, не всегда понятно и почти всегда – сухо и скучно.

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

6 марта 2009 в 11:10

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

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

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

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

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

Контроль версий (version control)
Автоматизированные сборки (build management)
Юнит-тестирование (unit-testing)
Статический анализ кода (static source code analysis)
Генерация документации на основе исходного кода (javaDoc, phpDoc, Doxygen итп)
Непрерывная интеграция (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

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

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

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

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

Аннотация: Понятие конфигурационного управления. Управление версиями. Понятие "ветки" проекта. Управление сборками. Средства версионного контроля. Единицы конфигурационного управления. Понятие baseline.

Проблема

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

Рассмотрим теперь проект по разработке программного обеспечения . Что в нем является аналогом материальных активов на обычном производстве? Определенно, не столы и стулья, которыми пользуются разработчики. И даже не компьютеры, запчасти к ним и прочее оборудование. Учета и контроля, сродни складскому, требуют файлы проекта. В программном проекте их очень много – сотни и тысячи даже для относительно небольших проектов. Ведь создать новый файл очень легко. Многие технологии программирования поддерживают стиль, когда, например, для каждого класса создается свой отдельный файл.

Файл – это виртуальная информационная единица. В чем главное отличие файла от материальных единиц учета? В том, что у файла может быть версия , и не одна, и породить эти версии очень легко – достаточно скопировать данный файл в другое место на диске. В то время как материальные предметы существуют на складе сами по себе, и для них нет понятия версии. Да, может быть несколько однотипных предметов, разных заготовок изделия различной степени готовности. Но все это не то….. А версия файла – это очень непростой объект. Чем одна версия отличается от другой? Несколькими строчками текста или полностью обновленным содержанием? И какая из двух и более версий главнее, лучше? К этому добавляется еще и то, что многие рабочие продукты могут состоять из набора файлов, и каждый из них может иметь по несколько версий. Как собрать корректную версию продукта ?

В итоге в программном проекте начинают происходить мистические и загадочные события.

Тщательно оттестированная программа на показательных испытаниях не работает
Функциональность, о которой долго просил заказчик и которая была, наконец, добавлена в продукт, и новая версия торжественно отослана заказчику, таинственным образом исчезла из продукта.
На компьютере разработчика программа работает, а у заказчика – нет….

Разгадка проста – все дело в версиях файлов. Там, где все хорошо, присутствуют файлы одной версии, а там, где все плохо – другой. Но беда в том, что "версия всего продукта" – это абстрактное понятие. На деле есть версии отдельных файлов. Один или несколько файлов в поставке продукта имеют не ту версию – все, дело плохо. Необходимо управлять версиями файлов, а то подобная мистика может стать огромной проблемой.

Она серьезно тормозит внутреннюю работу. То разработчики и тестеры работают с разными версиями системы, то итоговая сборка системы требует специальных усилий всего коллектива. Более того, возможны неприятности на уровне управления. Различные курьезные ситуации, когда заявленная функциональность отсутствует или не работает (опять не те файлы послали!), могут сильно портить отношения с заказчиком. Недовольный заказчик может потребовать даже денежной компенсации за то, что возникающие ошибки слишком подолгу исправляются. А будет тут не долго, когда разработчики не могут воспроизвести и исправить ошибку, так как не могут точно определить, из каких же исходных текстов была собрана данная версия!

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

Выделим две основные задачи в конфигурационном управлении – управление версиями и управление сборками . Первое отвечает за управление версиями файлов и выполняется в проекте на основе специальных программных пакетов – средств версионного контроля . Существует большое количество таких средств – Microsoft Visual SourceSafe, IBM ClearCase, cvn, subversion и др. Управление сборками – это автоматизированный процесс трансформации исходных текстов ПО в пакет исполняемых модулей, учитывающий многочисленные настройки проекта, настройки компиляции , и интегрируемый с процессом автоматического тестирования . Эта процедура является мощным средством интеграции проекта, основой итеративной разработки.

Единицы конфигурационного управления

Так чем же мы управляем в рамках этой деятельности ? Любыми ли файлами, которые имеются в проекте? Нет, не любыми, а только теми, которые изменяются. Например, файлы с используемым в проекте покупным ПО должны себе спокойненько покоиться на CD - дисках или в локальной сети . Книги, документы с внешними стандартами, используемыми в проекте (например, в телекоммуникациях очень много разных стандартов на сетевые интерфейсы ) и пр. также должны просто храниться там, где каждый желающий их может взять. Как правило, такой информации в проекте немного, но, разумеется, она должна быть в порядке. Однако ради этого специальный вид деятельности в проекте не нужен.

Итак, конфигурационное управление имеет дело с меняющимися в процессе продуктами, состоящими из наборов файлов. Такие продукты принято называть единицами конфигурационного управления ( configuration management items ). Вот примеры:

пользовательская документация;
проектная документация;
исходные тексты ПО;
пакеты тестов;
инсталляционные пакеты ПО;
тестовые отчеты .

У каждой единицы конфигурационного управления должно быть следующее.

Структура – набор файлов. Например, пользовательская документация в html должна включать индекс-файл и набор html -файлов, а также набор вынесенных картинок ( gif или jpeg -файлы). Эта структура должна быть хорошо определена и отслеживаться при конфигурационном управлении – что все файлы не потеряны и присутствуют, имеют одинаковую версию, корректные ссылки друг на друга и т.д.
Ответственное лицо и, возможно, группу тех, кто их разрабатывает, а также более широкую и менее ответственную группу тех, кто пользуется этой информацией. Например, определенной программной компонентой могут в проекте пользоваться многие разработчики, но отвечать за ее разработку, исправление ошибок и пр. должен кто-то один.
Практика конфигурационного управления – кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления в средство управления версиями, правила именования и комментирования элемента в этой версии, дальнейшие манипуляции с ним там и пр. Более высокоуровневые правила, связанные, например, с правилами изменения тестов и тестовых пакетов при изменении кода. Однако, где-то здесь лежит водораздел между конфигурационным управлением и иными видами деятельности в проекте
Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ. Есть не у всех элементов, например, может не быть у документации, тестовых пакетов.

Элементы конфигурационного управления могут образовывать иерархию . Пример представлен на рис. 6.1 .

Рис. 6.1.

Управление версиями

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

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

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

V1.0 – ветвь, соответствующая выпущенному релизу . Внесение изменений в такие ветви запрещены и они хранят образ кода системы на момент выпуска релиза.
Fix V1.0.1 – ветвь, соответствующая выпущенному пакету исправлений к определенной версии. Подобные ветви ответвляются от исходной версии, а не от основной ветви и замораживаются сразу после выхода пакета исправлений.
Upcoming (V1.1) – ветвь, соответствующая релизу , готовящемуся к выпуску и находящемуся в стадии стабилизации. Для таких ветвей, как правило, действуют более строгие правила и работа в них ведется более формально.
Mainline – ветвь, соответствующая основному направлению развития проекта. По мере созревания именно от этой ветви отходят ветви готовящихся релизов.
WCF Experiment – ветвь, созданная для проверки некоторого технического решения, перехода на новую технологию, или внесения большого пакета изменений, потенциально нарушающих работоспособность кода на длительное время. Такие ветви, как правило, делаются доступными только для определенного круга разработчиков и убиваются по завершению работ после интеграции с основной веткой.

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

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

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

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

несоответствие друг другу различных частей проекта;
наличие специфических ошибок, возникших из-за того, что отдельные проекты разрабатывались без учета параметров

Конфигурационное управление имеет дело с меняющимися в процессе продуктами, состоящими из наборов файлов. Такие продукты принято называть единицами конфигурационного управления (configuration management items ). Вот примеры:

пользовательская документация;
проектная документация;
исходные тексты ПО;
пакеты тестов;
инсталляционные пакеты ПО;
тестовые отчеты .

У каждой единицы конфигурационного управления должно быть следующее.

Структура – набор файлов. Например, пользовательская документация в html должна включать индекс-файл и набор html -файлов, а также набор вынесенных картинок (gif или jpeg -файлы). Эта структура должна быть хорошо определена и отслеживаться при конфигурационном управлении – что все файлы не потеряны и присутствуют, имеют одинаковую версию, корректные ссылки друг на друга и т.д.
Ответственное лицо и, возможно, группу тех, кто их разрабатывает, а также более широкую и менее ответственную группу тех, кто пользуется этой информацией. Например, определенной программной компонентой могут в проекте пользоваться многие разработчики, но отвечать за ее разработку, исправление ошибок и пр. должен кто-то один.
Практика конфигурационного управления – кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления в средство управления версиями, правила именования и комментирования элемента в этой версии, дальнейшие манипуляции с ним там и пр. Более высокоуровневые правила, связанные, например, с правилами изменения тестов и тестовых пакетов при изменении кода.
Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ. Есть не у всех элементов, например, может не быть у документации, тестовых пакетов.

Элементы конфигурационного управления могут образовывать иерархию .

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

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

V1.0 – ветвь, соответствующая выпущенному релизу . Внесение изменений в такие ветви запрещены и они хранят образ кода системы на момент выпуска релиза.
Fix V1.0.1 – ветвь, соответствующая выпущенному пакету исправлений к определенной версии. Подобные ветви ответвляются от исходной версии, а не от основной ветви и замораживаются сразу после выхода пакета исправлений.
Upcoming (V1.1) – ветвь, соответствующая релизу , готовящемуся к выпуску и находящемуся в стадии стабилизации. Для таких ветвей, как правило, действуют более строгие правила и работа в них ведется более формально.
Mainline – ветвь, соответствующая основному направлению развития проекта. По мере созревания именно от этой ветви отходят ветви готовящихся релизов.
WCF Experiment – ветвь, созданная для проверки некоторого технического решения, перехода на новую технологию, или внесения большого пакета изменений, потенциально нарушающих работоспособность кода на длительное время. Такие ветви, как правило, делаются доступными только для определенного круга разработчиков и убиваются по завершению работ после интеграции с основной веткой.

Сборка (построение.exe или dll файла) объединяет множество файлов, разработанных разными программистами. В связи с этим процедуру сборки проекта часто автоматизируют, то есть выполняют не из среды разработки , а из специального скирпта – build -скрипта . Этот скрипт используется тогда, когда разработчику требуется полная сборка всего проекта. А также он используется в процедуре непрерывной интеграции (continues integration ) – то есть регулярной сборке всего проекта (как правило – каждую ночь). Как правило, процедура непрерывной интеграции включает в себя и регрессионное тестирование , и часто – создание инсталляционных пакетов.

Тестировщики должны тестировать по возможности итоговую и целостную версию продукта, так что результаты регулярной сборки оказываются очень востребованы. Кроме того, наличие базовой, актуальной, целостной версии продукта позволяет организовать разработку в итеративно-инкрементальном стиле, то есть на основе внесения изменений. Такой стиль разработки называется baseline -метод.

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

Baseline может быть совсем простой – веткой в средстве управления версиями, где разработчики хранят текущую версию своих исходных кодов. Единственным требованием в этом случае может быть лишь общая компилируемость проекта.

Baseline может также поддерживаться непрерывной интеграцией.

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

Стандартизация в современном бизнесе и промышленности . Развитие мирового рынка привело к тому, что многие товары и услуги стали распространяться по всему миру, стали развиваться глобальные сервисы, в частности, телекоммуникационные, банковские. Для того, чтобы устранить технические барьеры в промышленности, торговле и бизнесе, которые возникли вследствие того, что в разных странах для одних и тех же технологий и товаров действовали разнородные стандарты, стали создаваться национальные и международные комитеты по стандартизации. Остановимся на самых известных международных комитетах.

1865 год – образован комитет, который ныне называется ITU (International Telecommunication Union ). Сейчас штаб-квартира в Женеве (Швейцария), а ITU является частью ООН. Его основная задача – стандартизация телекоммункационных протоколов и интерфейсов с целью поддержания и развития глобальной мировой телекоммуникационной сети . Самыми известными стандартами ITU являются:

ISDN (цифровая телефонная связь, объединяющая телефонные сервисы и передачу данных ),
ADSL (широко известная модемная технология, позволяющая использовать телефонную линию для выхода в Интернет , не блокируя при этом обычного телефонного сервиса ),
OSI (модель открытого 7-уровневого сетевого протокола , на которой базируются все современные стандартные сетевые интерфейсы и протоколы ; также является стандартом ISO ),
языки визуального проектирования телекоммуникационных систем, SDL и MSC , влившиеся позднее в UML .

Многие стандарты ITU переводятся на русский язык и превращаются в российские стандарты в виде ГОСТов.

1946 год – создана организация ISO (International Organization for Standardization ). Цель – содействие развитию стандартизации, а также смежных видов деятельности в мире с целью обеспечения международного обмена товарами и услугами, способствование и развитие сотрудничества в интеллектуальной, научно-технической и экономической областях. К настоящему времени создано около 17 000 стандартов в самых разных областях промышленности – продовольственные и иные товары, различное оборудование, банковские сервисы и т.д. Вот некоторые стандарты.

Серия стандартов ISO 9000 . Направлены на стандартизацию качества товаров и услуг. Определение качества, определение системы поддержки качества на всех жизненных фазах изделия, товара, услуги (проектирование, разработка, коммерциализация, установка и обслуживание), описание процедур по улучшению деятельности компании, промышленного производства.
ISO /IEC 90003:2004 – адаптация стандартов ISO 9000 к производству ПО в русле обеспечения качества в жизненном цикле ПО.
ISO 9126:2001 – определение качественного ПО и различных атрибутов, описывающих это качество.

Многие стандарты ISO переводятся на русский язык и превращаются в российские стандарты в виде ГОСТов. Имеется много стандартов в области информационных технологий , а также несколько – в области программной инженерии . На соответствие стандартам ISO существует сертификация. В частности, компании сертифицируются на соответствие стандартам ISO 9000 , то есть на качественный процесс разработки ПО.

1988 год, образование организации ETSI (European Telecommunications Standards Institute), штаб-квартира в г. София Антиполис (Франция). Является независимой, некоммерческой, организацией по стандартизации в телекоммуникационной промышленности (изготовители оборудования и операторы сети) в Европе. Самые известные стандарты – GSM , система профессиональной мобильной радиосвязи TETRA .

Остановимся теперь на ряде комитетов, непосредственно связанных с разработкой ПО.

1984 год – создание SEI (Software Engineering Institute) на базе университета Карнеги-Меллон в г.Питсбурге (США). Инициатор и главный спонсор – министерство обороны США. Основная задача – стандартизация в области программной инженерии , выработка критериев для сертификации надежных и зрелых компаний (что в первую очередь интересует Минобороны США для выполнения его заказов). Самые известные продукты – стандарт CMM , CMMI , разработки в области семейства программных продуктов (product lines). Эти продукты шагнули далеко за пределы военных разработок США, их использование и развитие стало международной деятельностью. Некоторые продукты SEI стандартизованы такжеISO . На соответствие CMM /CMMI проводится сертификация.
1963 год – создание IEEE (Institute of Electrical and Electronics Engineers ). Ведет историю с конца XIX века, в контексте промышленной стандартизацией в США. Сейчас IEEE международная некоммерческая ассоциация специалистов в области техники, мировой лидер в области разработки стандартов по радиоэлектронике и электротехнике. Штаб-квартира в США, существуют многочисленные подразделения в разных странах, включая Россию. IEEE издаёт третью часть мировой технической литературы, касающейся применения радиоэлектроники, компьютеров, систем управления, электротехники, в том числе (январь 2008) 102 реферируемых научных журнала и 36 отраслевых журналов для специалистов, проводит в год более 300 крупных конференций, принимала участие в разработке около 900 действующих стандартов.
1989 год – группа американских IT-компаний (в том числе Hewlett Packard, Sun Microsystems , Canon ) организовали OMG (Object Management Group ). Сейчас включает около 800 компаний членов. Основное направление - разработка и продвижение объектно-ориентированных технологий и стандартов, в том числе для создания платформо-независимых программных приложений уровня предприятий. Известные стандарты CORBA , UML , MDA .

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

Стандартизация качества . С точки зрения тестирования ПО нас интересует в этих стандартах стандартизация качества (как контекст тестирования) – сначала выпускаемой продукции, а потом и процессов по ее разработке. Здесь срабатывает идея о том, что качественного результата не создать без качественного процесса. Обеспечение качества является более общим контекстом для тестирования.

Качество продукта или сервиса , предназначенного потребителю, определяется в стандарте ISO 9000 :2005 как степень соответствия его характеристик требованиям - обязательным или подразумеваемым.

Методы обеспечения качества ПО . Не претендуя на абсолютную полноту , перечислим различные способы контроля качества , используемые на практике при разработке ПО.

Наладка качественного процесса, другими словами совершенствование процесса. Для комплексного улучшения процессов в компании (подход technology push ) компаниями-разработчиками ПО используются стандарты CMM /CMMI , а также по стандартам серии ISO 9000 (с последующей официальной сертификацией ). Применяются и локальные стратегии, менее дорогостоящие и более направленные на решение отдельных проблем (подход organization pull ).
Формальные методы 1) – использование математических формализмов для доказательства корректности , спецификации, проверки формального соответствия, автоматической генерации и т.д.:

доказательство правильности работы программ,
проверка на моделях определенных свойств (model cheking),
статический анализ кода по дереву разбора программы (например, проверка корректности кода по определенным критериям – аккуратная работа с памятью, поиск мертвого кода и пр.),
модельно-ориентированное тестирование (model-based testing ): автоматическая генерация тестов и тестового окружения по формальным спецификациям требований к системе) и т.д.

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

Исследование и анализ динамических свойств ПО. Например, широко используется профилирование – исследование использования системой памяти, ее быстродействие и др. характеристик путем запуска и непосредственных наблюдений в виде графиков , отчетов и пр. В частности, этот подход используется при распараллеливании программ, при поиске "узких" мест. Еще пример – область, называемая "моделирование и анализ производительности " (performance modeling and analysis ). Здесь моделируется нагрузочное окружение системы (число одновременных пользователей системы, сетевой трафик и пр.) и наблюдается поведение системы.
Обеспечение качества кода. Сюда относится целый комплекс различных мероприятий и методов. Вот некоторые, самые известные из них.

Разработка стандартов оформления кода в проекте и контроль за соблюдением этих стандартов. Сюда входят правила на создание идентификаторов переменных , методов и имен классов, на оформление комментариев, правила использования стандартных для проекта библиотек и т.д.
Регулярный рефакторинг для предотвращения образования из кода "вермишели". Существует тенденция ухудшения структуры кода при внесении в него новой функциональности, исправления ошибок и пр. Появляется избыточность , образуются неиспользуемые или слабо используемые фрагменты , структура становится запутанной и трудной для понимания. Рефакторинг – это регулярная деятельность по переписыванию кода, но не с целью добавления новой функциональности, а для улучшения его структуры. Рефакторинг появился в контексте "гибких" методов, в данный момент активно поддерживается различными средами разработки ПО.
Различные варианты инспекции кода, например, техника peer code review . Последняя заключается в том, что код каждого участника проекта, выборочно, читается и обсуждается на специальных встречах (code review meetings), и делается это регулярно. Практика показывает, что в целом код улучшается.
Еcть еще такой подход, как "вычитка" кода, используемый, например, при разработке критических систем реального времени. Ею занимаются также разработчики, но их роль в данном проекте – вычитка, а не разработка.

Тестирование. Самый распространенный способ контроля качества ПО, представленный, фактически, в каждом программном проекте.

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

В большинстве случаев после принятия решения об управлении основными элементами ИТ-инфраструктуры все силы бросают на наполнение CMDB, в которую заносится максимальное количество информации об CI. Через некоторое время информация начинает терять актуальность, разрушаются связи между объектами, появляется нехватка описания не физических, а логических объектов инфраструктуры – все это приводит к отказу от дальнейшего развития. Причина неудач кроется в неправильной оценке внедрения процесса управления конфигурацией, ведь он включает в себя не только базу данных, но и логику в ее заполнении, актуализации и развитии.

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

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

Важность управления конфигурацией

Порой старшие менеджеры говорят, что у них нет денег на покупку дорогостоящих систем для управления конфигурацией (CMSs). Но, принимая такое решение, они не получают контроля над всеми расходуемыми средствами, связанными с восстановлением ИТ и бизнес-услуг; над внесением изменений, без контроля последствий их применения и возможных неблагоприятных последствий для бизнеса; над управлением и оптимизацией затрат на ИТ-имущество и управлением релизами без связи с другими процессами.

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

А также время, которое вы вынуждены тратить на отчеты для руководства о снижении ключевых бизнес-сервисов, так как изменили систему управления; на объяснение клиентам о задержке устранения инцидента с ИТ-инфраструктурой из-за отсутствия системы CMS; на устранение дефектов релиза из-за плохого управления имуществом.

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

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

С чего стоит начать

В-первую очередь необходимо объяснить цель и смысл использования управления конфигурацией всем заинтересованным сторонам, включая владельцев систем, сетевых инженеров и других. Члены команды управления конфигурацией и специалисты, ответственные за данные, которые она содержит, должны предоставлять точную информацию коллегам, решающим инциденты и планирующим изменения. И наоборот: действия, производимые ИТ-специалистами с другими системами, должны отображаться в CMS или базе данных управления конфигурацией (CMDB). Каждая сторона рабочего процесса должна принимать непосредственное участие в управлении конфигурацией – это путь к достижению успеха, это необходимо знать и понимать каждому.

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

В целом внедрение управления конфигурацией можно разделить на 5 этапов:

планирование,
определение (в том числе исходного состояния),
контроль,
учет состояния,
проверка и аудит.

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

Составление плана

Мы рекомендуем начать планирование управления конфигурацией с наиболее критичных и важных для бизнеса процессов, таких как управление инцидентами и проблемам. Служба технической поддержки всегда загружена заявками от пользователей, и их своевременное исполнение – одна из головных болей руководства. Если вы начнете реализацию проекта именно с этих услуг, это поможет снизить нагрузку и оптимизировать работу специалистов Service Desk и результат заметят другие подразделения компании. Руководство обратит внимание на более быстрое разрешение инцидентов, уменьшение времени простоя, снижение числа неудачных изменений и обеспечит вас поддержкой для дальнейшей реализации.

Условно можно выделить 3 основных элемента (уровня) конфигурации:

конфигурация;
актив;
материально-технический ресурс.

Их распределение отображено на представленной ниже диаграмме.

Конфигурационные единицы (CI) являются строительными блоками для критически важных сервисов, они включают в себя серверы, маршрутизаторы, программное обеспечение и системы, на которых оно построено. Чтобы управлять всем этим, требуется много времени, денег и сил, поэтому мы рекомендуем сосредоточиться только на ключевых сервисах, чтобы не переполнить CMS и CMDB лишней информацией, а занести действительно нужную.
Активы – ПК, ноутбуки и другая техника, которая находится на финансовом контроле, но не требует управления.
Материально-технические ресурсы – это различные мелкие периферийные устройства, такие как клавиатуры, мышки, флешки и тому подобное.

Последовательность – ключ к планированию

При грамотном планировании важна последовательность действий и внимание к мелочам. Например, план может содержать описание способа формирования имен CI. Имя каждой единицы для CMDB должно быть уникально и содержать ключевую информацию, которая помогает ее идентифицировать. Примером может служить такая маска: Тип CI – расположение – служба поддержки. Имя CI «MSserver-Moscow-Level3» говорит оператору Service Desk о том, что Windows Server на московской площадке недоступен и нуждается в технической поддержке третьей группой. Такой уровень информации при регистрации инцидента позволяет сразу предупредить всех пользователей сервера о проблеме, а также назначить тикет именно той группе поддержки, которая за него отвечает, что сокращает время реакции за счет сокращения стадий эскалации.

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

План конфигурации должен быть масштабируемым

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

Управление конфигурацией – это один из кирпичиков эффективного использования ИТ-инфраструктуры компании и качественного предоставления услуг. Если к нему добавить такие процессы, как управление активами и управление мощностями, то вы получите комплексную модель гибкого и рационального использования всех имеющихся в вашем распоряжении ресурсов. О внедрении и эксплуатации этих процессов мы расскажем в следующих материалах нашего блога.

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

Чтобы прямо сейчас испытать все возможности и преимущества популярной и успешной сервисной платформы ServiceNow, в том числе для управления конфигурацией, вы можете обратиться к специалистам компании – официального сертифицированного партнера ServiceNow.

Подписывайтесь на блог компании – официального сертифицированного партнера ServiceNow, чтобы следить за новыми статьями, которые позволят вам достигнуть успеха, внедряя платформу.

Документы