Применение средств конфигурационного управления (SCM - Software Configuration Management) тесно связано с методиками конфигурационного управления, которые существуют в рамках и определяются организацией процесса разработки ПО. Связь эта очень тесная, другими словами, организация процесса разработки и, главное, ее тенденции выражаются в конфигурационном управлении и его средствах. Вот об этих трех взаимосвязанных вещах и пойдет речь.

Что такое конфигурационное управление

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

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

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

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

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

Бухгалтерский учет как учет изменений. Что учитывает бухгалтерия? Многочисленные операции, состоящие в передаче денег и других материальных ценностей нематериальным способом. Учитываемые в бухгалтерии хозяйственные операции в совокупности образуют финансовое состояние хозяйствующего субъекта, - состояние почти столь же изменчивое, как и состояние в процессе разработки информационной системы. Нет ничего необычного в том, что механизм управления изменениями состояния - бухгалтерский учет - имеет много общего с конфигурационным управлением.

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

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

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

Так что же такое SCM? Наиболее простое и в то же время достаточно полное определение того, что такое конфигурационное управление, содержится в документации к PVCS.

“Конфигурационное управление, - считает фирма Intersolv (разработчик PVCS), - это организация изменений и управления изменением компонентов в процессе разработки программного обеспечения”.

Это некоторая сквозная деятельность (активность, “вспомогательный процесс” в терминологии стандарта ISO 12207-1), выполняемая в течение всего производственного процесса. Определение не учитывает конфигурационного управления на этапе поддержки информационной системы, но оно вполне достаточно для выявления характерных черт SCM.

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

Проблема автоматизации конфигурационного управления

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

Дисциплина конфигурационного управления. Прежде всего, конфигурационное управление существует как дисциплина, изложенная в стандартах. Из них можно отметить следующие:

Стандарт IEEE Std-828 и заменивший его IEEE Std-1042;

Стандарт ANSI, основанный на IEEE Std-828.

Стандарт ISO 12207, основанный на IEEE Std-828.

На основании упомянутых (или иных - например, корпоративных) стандартов для каждого проекта разрабатываются документы, содержащие в себе методику конфигурационного управления. Эти стандарты и методики учитывают сложный характер современной групповой разработки программных проектов. В SCMP (SoftWare Configuration Management Plan) детально расписываются все действия, обязанности и ответственность участников проекта по отношению к SCM.

Действующие в России стандарты (19-я и 34-я серии ГОСТов) не содержат предписаний, касающихся конфигурационного управления, хотя советская программная инженерия выработала оригинальные подходы - достаточно упомянуть сборочное программирование, представляющее собой систему как проектирования, так и конфигурационного управления. В отсутствие национальных стандартов должны применяться стандарты международные, в частности, по отношению к конфигурационному управлению документом прямого действия является ISO 12207-2.

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

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

Это разделение процесса разработки на “действия” (терминология ISO 12207-1), соответствующее этапам жизненного цикла, дополняется распределением задач по отдельным исполнителям и группам. Разнообразие действий, задач и исполнителей образует среду современной организации разработки.

Средства автоматизации конфигурационного управления. Для автоматизации многих действий конфигурационного управления разработаны многочисленные программные средства.

Ниже мы будем рассматривать почти исключительно PVCS. Средства PVCS очень широко распространены и фактически стали стандартом в области конфигурационного управления. Мне даже приходилось слышать, как SourceSafe (средство версионного хранения фирмы Microsoft) называли PVCS’ом.

ОРГАНИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПО И КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ

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

Куда вносятся изменения?

Кто вносит изменения?

Какова процедура внесения изменений?

Как процедура внесения изменений связана с объектом изменения, этапом разработки, лицом, вносящим изменения?

Жизненный цикл. Жизненный цикл современной разработки состоит из ряда стадий (фаз), на которых могут изменяться не только исходные коды, но и другие объекты.

Рассмотрим вначале каскадный жизненный цикл разработки ПО. В нем выделяют обычно следующие этапы:

Анализ требований (на этом этапе создаются и изменяются текстовые документы, содержащие требования к системе, часто эти документы могут содержать диаграммы той или иной методики анализа);

Проектирование (на этом этапе создается и/или изменяется представление о создаваемой программной системе в виде тех или иных методик проектирования; также на этапе детального проектирования (дизайна) могут создаваться первоначальные версии исходных текстов;

Кодирование (на этом этапе создаются и изменяются исходные тексты, а также исполняемые, т. е. коды, непосредственно используемые для исполнения машиной [если они отличны от исходных кодов]);

Тестирование (на этом этапе создаются тестовые процедуры, включая тестовые данные, а также результаты их выполнения);

Сопровождение (на этом этапе изменения как таковые не вносятся [внесение изменений здесь можно рассматривать как кратковременный откат к предшествующим этапам], основной рассматриваемый объект - выпускаемые версии).

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

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

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

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

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

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

Георгий Серяков

(Окончание следует)

Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной 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 (см. ссылки в конце), там это рассматривается много и плодотворно. Правда, не всегда понятно и почти всегда – сухо и скучно.

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

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

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

Конфигурационная единица (Configuration Item или CI) - любой компонент , который нуждается в управлении для того, чтобы предоставлять услугу. Информация о каждой КЕ регистрируется в форме Записи о КЕ в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. КЕ находятся под контролем Управления изменениями. Типичными примерами КЕ являются услуги, оборудование, программное обеспечение , здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг ( SLA ).

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

• СI жизненного цикла - бизнес-кейс, планы сервис-менеджмента, проектная документация, планы релизов, изменений и тестирования. Эти конфигурационные единицы предоставляют полную картину об услугах поставщика и их предоставлении, ожидаемых выгод от использования, затратах и сроках релиза.
• CI услуг:
  • возможности услуг - управление, организация, процессы, знания, люди;
  • ресурсы услуг - капитал, системы, приложения, информация, данные, инфраструктуры и т.п.;
  • модель услуг;
  • пакет услуг;
  • пакет релизов;
  • критерии приемки услуг.
• CI организации. Некоторая документация определяет характеристики CI, некоторая сама является CI и требует контроля, например, стратегия бизнеса или политика организации;
• внутренние СI - материальные и нематериальные активы, которые необходимы для предоставления и управления услугами;
• внешние CI - требования заказчиков, соглашения, релизы поставщиков и внешние услуги;
• CI интерфейсов - активы, необходимые для предоставления услуг "от начала до конца" в рамках Интерфейса поставщика услуг. Интерфейс поставщика услуг (Service Provider Interface или SPI) - интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами.

Рассмотрим подробнее деятельности, представленные на рис. 8.4 .

Управление и планирование

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

Идентификация конфигураций

Для идентификации конфигураций важно:

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

Деятельность в рамках идентификации конфигураций включает в себя:

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

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

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

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

• уникальный идентификатор;
• тип CI;
• имя/описание;
• версия;
• расположение;
• дата поставки;
• детали лицензии (в частности, дата ее истечения);
• владелец/куратор;
• статус;
• поставщик/источник;
• документация;
• данные истории, например, аудиторские отчеты;
• тип связей;
• соответствующий SLA.

Чаще всего характеристики CI содержатся в документации к ней. Связи конфигурационных единиц отражают то, как они взаимодействуют друг с другом в процессе предоставления услуг. Информация о связях хранится в CMS .

Основные связи между CI:

• CI является частью другой CI. Например, сервер является частью инфраструктуры сайта. Это отношение "родитель-ребенок";
• CI соединен с другим CI. Например, персональный компьютер соединен с локальной сетью;
• CI использует другой CI. Например, программа использует модуль другой программы;
• CI установлена на другую CI, например, Microsoft Excel на персональный компьютер.

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

Контроль конфигураций

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

• лицензионный контроль - проверяет количество людей, которые используют лицензионный продукт, следит за тем, чтобы в организации не использовались нелицензионные продукты, следит за сроками истечения лицензий и т.п.;
• управление изменениями;
• контроль версий активов, программного и аппаратного обеспечения, релизов, сборок и т.п.;
• контроль активов - возможности, место хранения, CMS;
• контроль сборки с использованием документации от CMS;
• поддержка и миграция электронных данных и информации;
• формирование базы активов и конфигурационных единиц перед релизом;
• контроль развертывания;
• инсталляция;
• управление целостностью Библиотеки эталонного ПО. Библиотека эталонного ПО (Definitive Media Library (DML) - одно или несколько защищенных хранилищ, в которых находятся определенные и авторизованные версии всех конфигурационных единиц, относящиеся к программному обеспечению. DML также может содержать CI, ассоциированные с ПО, такие как лицензии и документация. DML является логически единым хранилищем, даже если физически места хранения распределены. Все программное обеспечение в DML находится под контролем Управления изменениями и Управления релизами, должно быть зарегистрировано в Системе управления конфигурациями. В релизе может быть использовано только программное обеспечение из DML[

Программная инженерия

Конфигурационное управление

(Software Configuration Management)

Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK® , 2004. Содержит перевод описания области знаний SWEBOK® “Software Configuration Management”, с

комментариями и замечаниями.

"Основы программной инженерии" разработаны на базе IEEE Guide to SWEBOK® 2004 в соответствии с IEEE SWEBOK 2004 Сopyright and Reprint Permissions: "This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy."

Русский перевод SWEBOK 2004 с замечаниями и комментариями подготовлены Сергеем Орликом

при участии Юрия Булуя . Дополнительные главы написаныСергеем Орликом . Текст расширений SWEBOK отмечен ццветом, отличным от перевода оригинального текста.

"Основы программной инженерии" Сopyright © 2004-2010 Сергей Орлик . Все права защищены.SWEBOK Сopyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved.

Официальный сайт “Основ программной инженерии” (по SWEBOK) - http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)
Программная инженерия. Конфигурационное управление.
Программная инженерия
Конфигурационное управление (Software Configuration Management)
Программная инженерия..........................................................................................................................
Конфигурационное управление (Software Configuration Management) ................................................
1. Управление SCM-процессом (Management of SCM Process) .......................................................
	Организационный контекст SCM (Organizational Context for SCM) .........................................
	Ограничения и правила SCM (Constraints and Guidance for the SCM Process).......................
	Планирование в SCM (Planning for SCM).................................................................................
	План конфигурационного управления (SCM Plan) ..................................................................
	Контроль выполнения SCM-процесса (Surveillance of Software Configuration Management) ..
2. Идентификация программных конфигураций (Software Configuration Identification) ..................
	Идентификация элементов, требующих контроля (Identifying Items to Be Controlled)..........
	Программная библиотека (Software Library) ..........................................................................
3. Контроль программных конфигураций (Software Configuration Control) .....................................
	Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving
Software Changes) ........................................................................................................................
	Реализация изменений (Implementing Software Changes).....................................................
	Отклонения и отказ от изменений (Deviations and Waivers) ..................................................
4. Учет статусов конфигураций (Software Configuration Status Accounting)....................................
	Информация о статусе конфигураций (Software Configuration Status Information)................
	Отчетность по статусу конфигураций (Software Configuration Status Reporting)...................
5. Аудит конфигураций (Software Configuration Auditing) ................................................................
	Функциональный аудит программных конфигураций (Software Functional Configuration Audit)
......................................................................................................................................................
	Физический аудит программных конфигураций (Software Physical Configuration Audit) .......
	Внутренние аудиты базовых линий (In-process Audits of Software Baseline) ........................
6. Управление выпуском и поставкой (Software Release Management and Delivery) .....................
	Сборка программного обеспечения (Software Building).........................................................
	Управление выпуском программного обеспечения (Software Release Management)...........

Система может быть определена как коллекция компонент, организованных для выполнения заданных функций или реализации комплекса функциональности (IEEE 610.12-90, Standard Glossary for Software Engineering Terminology).Конфигурация системы – функциональные и/или физические характеристики аппаратного, программно-аппаратного, программного обеспечения или их комбинации, сформулированные в технической документации и реализованные в продукте. Конфигурация также может восприниматься как сочетание конкретных версий аппаратных, программно-аппаратных или программных элементов, объединенных вместе, в соответствии с заданными процедурами сборки и отвечающих определенному назначению.Конфигурационное управление (CM - Configuration Management), в свою очередь, дисциплина идентификации конфигурации системы в определенные (заданные) моменты времени, с целью систематического контроля изменений конфигурации, а также поддержки и сопровождения целостной и отслеживаемой (трассируемой) конфигурации на протяжении всего жизненного цикла системы.

Конфигурационное управление формально определяется глоссарием IEEE 610 как “дисциплина приложения технических и административных указаний (инструкций) и контроля (надзора) для: идентификации и документирования функциональных и физических характеристик элементов конфигураций, контроля (управления) изменений этих характеристик, записи (сохранения) и ведения отчетности по обработке изменений и статусу их реализации, а также проверки (верификации) соответствия заданным требованиям.”

В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207, конфигурационное управление в области программного обеспечения (“6.2 Управление конфигурацией” по ГОСТ) –Software Configuration Management (SCM*) – один из вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающих проектный менеджмент, деятельность по разработке и сопровождению, обеспечению качества, а также, заказчиков и пользователей конечного продукта.

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Конфигурационное управление.

* в ряде источников можно увидеть аббревиатуру SCCM – Software Configuration and Change Management. При том, что в понимании SWEBOK и соответствующих стандартов, содержание SCM и SCCM тождественно, термин SCCM иногда используется для того, чтобы подчеркнуть принципиальную значимость управления изменениями как составной части конфигурационного управления.

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

SCM-деятельность тесно связана с работами по обеспечению качества программного обеспечения (Software Quality Assurance - SQA ). В соответствии с определением области знаний SWEBOK “Качество программного обеспечения” (Software Quality), SQA-процессы обеспечивают гарантию того, что программные продукты и процессы жизненного цикла в проекте соответствуют заданным требованиям, за счет планирования и выполнения работ, направленных на достижение определенного (приемлемого,прим. автора ) уровня качества создаваемого программного продукта. SCM-деятельность помогает в достижении этих SQA-целей. В контексте некоторых проектов, определенные работы по конфигурационному управлению задаются требованиями SQA (например,

в IEEE 730-02 “Standard for Software Quality Assurance Plans”).

Работы по конфигурационному управлению <программного обеспечения> включают: управление и планирование SCM-процессов, идентификацию программных конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также управление выпуском (release management) и поставкой

На рисунке 1 изображено стилизованное представление этих работ.

Рисунок 1. Работы по конфигурационному управлению (SCM Activities)

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

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

является результатом непонимания того, что результаты проекта – это не только исходный код, исполняемые модули и пользовательская документация, но и все то, что создавалось (пусть и для

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Конфигурационное управление.

решения тактических задач, как это часто бывает с некоторыми моделями и результатами пилотных работ по созданию прототипов) на протяжении всего проекта . Активами проекта (результатами, артефактами) являются и описания бизнес-процессов и бизнес-сущностей, и архитектурные модели, и требования, и план проекта/проектные задачи (как комплекс параметров, связанных с распределением ресурсов), и запросы на изменения (включая информацию о дефектах) и многое другое. Безусловно, упрощение вопросов конфигурационного управления до уровня управления версиями, с коньюктурной точки зрения, выгодно многим поставщикам соответствующих инструментальных средств.В определенных случаях , особенно, для малых проектов или временно используемых/”одноразовых” систем (например, по односторонней, “one-way” миграции данных из унаследованной системы в новую),упрощенный взгляд на конфигурационное управление может быть вполне обоснован . Однако, как это ни прискорбно, часто приходится наблюдать позиционирование такой, с позволения сказать, “практики”, как некоего “стиля гибкой работы”, подменяющей реальную динамику и гибкость agile-подходов (например, XP) отсутствием управления (важно понимать и помнить, что управление далеко не всегда является директивным), как такового (например, по определению содержания проекта на основе консенсуса проектной команды и вовлеченных в проектные работы представителей заказчика). В свою очередь, даже когда все активы проекта находятся под контролем соответствующих SCM-систем, необходимо осознавать,

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

Рисунок 2. Область знаний “Конфигурационное управление”

1. Управление SCM-процессом (Management of SCM Process)

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

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Конфигурационное управление.

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

1.1 Организационный контекст SCM (Organizational Context for SCM)

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

Организационные элементы, отвечающие за процессы поддержки программной инженерии, могут быть структурированы несколькими способами. Несмотря на то, что ответственность за выполнение определенных SCM-задач может быть назначена (принята или ассоциирована, в зависимости от управленческих принципов и установок, т.е. общего менеджмента - general management) различным частям(лицам, группам, подразделениям и т.п. ) организации, например, структуре, отвечающей за разработку программного обеспечения, общая ответственность за конфигурационное управление часто возлагается на отдельный (специализированный) организационный элемент или назначенную персону.

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

SCM может играть роль интерфейса к работам, направленным на обеспечение качества (quality assurance), вытекающим, например, из отслеживания записей <по изменениям> и несогласующихся элементов (например, выявленным в процессе сборки очередной версии системы, прим. автора ). С точки зрения составителей <данной области знаний SWEBOK>, некоторые элементы, находящиеся под управлением SCM <процесса>, могут также служить объектами рассмотрения в рамках организационных программ по обеспечению качества. Управление несогласующемися элементами обычно относится к работам по управлению качеством. Однако, SCM может обеспечить существенную помощь в отслеживании (трассировке) и создании отчетности по элементам программных конфигураций, попадающих в такую <проблемную> категорию.

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

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

1.2 Ограничения и правила SCM (Constraints and Guidance for the SCM Process)

Ограничения и правила в отношении процесса конфигурационного управления порождаются различными источниками. Политики и процедуры, формулируемые на корпоративном или другом организационном уровне, могут влиять или предписывать структуру и реализацию SCM-процесса для заданного проекта. Кроме того, контракт между заказчиком и поставщиком может содержать положения, затрагивающие процесс конфигурационного управления. Например, может требоваться проведение определенных процедур проверки (аудита) или специфицирован набор элементов (активов, артефактов), передаваемых под управление <процедур и системы> конфигурационного управления (или в части формализации обработки и контроля реализации запросов на изменения, поступающих от заинтересованных лиц ). Когда разрабатываемый программный продукт потенциально затрагивает аспекты публичной безопасности, могут налагаться определенные ограничения со стороны соответствующих регулирующих органов (например, USNRC Regulatory Guide 1.169, “Configuration Management Plans for Digital Computer Software Used in Safety Systems of Nuclear

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Конфигурационное управление.

Power Plants”, U.S. Nuclear Regulatory Commission, 1997). Наконец, на структуру и реализацию SCM-

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

Рекомендации по структуре и реализации SCM-процесса могут быть также результатом применения лучших практик (best practices), представленных в стандартах, выпущенных соответствующими стандартизирующими организациями. Лучшие практики также отражены в моделях совершенствования и оценки процессов, например, в CMMI – Capability Maturity Model Integration Института программной инженерии (SEI – Software Engineering Institute) университета Карнеги-

Меллон (Carnegie-Mello University) и ISO/IEC 15504 (SPICE) “Software Engineering – Process Assessment”.

1.3 Планирование в SCM (Planning for SCM)

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

Идентификацию программных конфигураций (Software Configuration Identification)

Контроль конфигураций (Software Configuration Control)

Учет статусов конфигураций (Software Configuration Status Accounting)

Аудит конфигураций (Software Configuration Auditing)

Управление выпуском и поставкой (Software Release Management and Delivery)

Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного управления, как организационные вопросы, обязанности, ресурсы и расписание, выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а также, контроль интерфейсов <взаимодействия программных модулей>. Результаты планирования сводятся в план конфигурационного управления (SCM Plan - SCMP ), обычно, являющийся объектом оценки и аудита в рамках деятельности по обеспечению качества (SQA – Software Quality Assurance).

1.3.1 Организация и обязанности (SCM organization and responsibilities)

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

1.3.2 Ресурсы и расписание (SCM resources and schedules)

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

1.3.3 Выбор инструментов и реализация (Tool selection and implementation)

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

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Конфигурационное управление.

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

SCM-библиотек (проектно-ориентированных баз знаний,прим. автора )

Запросов на изменения (software change request - SCR) и процедур утверждения (approval)

Управления кодом (и связанных рабочих продуктов) и изменениями

Отчетности по статусу конфигураций и сбору соответствующих метрических показателей

Аудиту конфигураций

Управлению и отслеживанию <состояния и полноты> программной документации

Выполнению задач по сборке программных продуктов и их модулей

Управлению, контролю и поставке выпусков (релизов) программных продуктов

Инструменты, используемые для обеспечения конфигурационного управления, могут также предоставлять метрики, необходимые для совершенствования процессов. SWEBOK обращает внимание (рекомендуя соответствующий первоисточник ) на следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and Progress) и индикаторы качества – поток изменений (Change Traffic), стабильность <конфигураций> (Stability), раздробленность (Breakage), модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility), среднее время между сбоями (MTBF – Mean Time Between Failures), зрелость/полнота <информации> (Maturity).

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

Рисунок 3 демонстрирует отображение инструментальных возможностей и процедур на работы по конфигурационному управлению.

Рисунок 3. Характеристики SCM-инструментов и связанные процедуры.

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

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Конфигурационное управление.

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

В процессе планирования инженеры выбирают те SCM-средства, которые применимы для решения стоящих перед ними задач.

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

В процесс планирования рассматриваются аспекты, которые могут “всплыть” в процессе внедрения (и, даже, на этапе эксплуатации ) выбираемой системы конфигурационного управления. В частности, обсуждаются и вопросы возможных “культурных” изменений, если это необходимо (с точки зрения поставленных целей – проекта и/или совершенствования процессов ). Дополнительная информация, затрагивающая SCM-инструментарий, представлена в области знаний SWEBOK “Software Engineering Tools and Methods”.

1.3.4 Контроль поставщиков/подрядчиков (Vendor/Subcontractor Control)

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

Аналогичные соображения существуют и в отношении программного обеспечения, создаваемого подрядчиками. В этом случае, в отношении SCM-процесса подрядчика предъявляются специальные требования со стороны заказчика и они вносятся в контракт, предполагая не только возможность мониторинга, но и соответствие его возможностей заданным требованиям. В последнее время все чаще отмечается важность доступности SCM-информации для эффективного мониторинга соответствия (compliance monitoring).

1.3.5 Контроль интерфейсов (Interface Control)

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

1.4 План конфигурационного управления (SCM Plan)

http://swebok.sorlik.ru

Основы программной инженерии (по SWEBOK)

Программная инженерия. Конфигурационное управление.

Результаты SCM-планирования для заданного проекта определяются вплане конфигурационного управления (Software Configuration Management Plan, SCMP ), который является документом,

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

Создание и сопровождение плана конфигурационного управления основывается на информации, получаемой в процессе работ по планированию. Рекомендации по созданию и сопровождению SCMP можно найти, например, в одном из ключевых SCM-стандартов IEEE 828-98 “Standard for Software Configuration Management Plans” . Этот стандарт описывает требования к информации, содержащейся в плане конфигурационного управления, а также определяет шесть категорий SCMинформации, содержащейся в плане (обычно, представленных в виде соответствующих разделов,

Введение (Introduction) – описывает цели, содержание и используемые термины.

Управление (SCM Management) – описывает структуру, обязанности, полномочия, политики, директивы (указания, обязательные для исполнения) и процедуры.

Работы (SCM Activities) – определяет идентификацию конфигураций, их контроль и т.п.

Расписание (SCM Schedule) – определяет связь работ по конфигурационному управлению с другими аспектами и процессами проектной деятельности

Ресурсы (SCM Resources) – описывает инструменты, физические ресурсы, персонал и т.п.

Сопровождение плана (SCMP Maintenance) – определяет правила, по которым в план вносятся изменения и описывает как эти изменения внедряются в повседневный SCMпроцесс.

1.5 Контроль выполнения SCM-процесса (Surveillance of Software Configuration Management)

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

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

1.5.1 Метрики и процесс количественной оценки в SCM (SCM measures and measurement)

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

Программные библиотеки и различные возможности SCM-средств предоставляют источники для получения информации о характеристиках SCM-процесса (наравне с проектной информацией и

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

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

Оркестровка – ещё одна важная составляющая продуктивного управления конфигурациями. Инструменты для оркестровки позволяют управлять огромным количеством серверов (до сотен) с помощью одного ведущего сервера.

Сегодня существует огромное количество инструментов для управления конфигурациями, самыми популярными являются Puppet, Ansible, Chef и Salt. Каждый инструмент имеет свои особенности и преимущества, однако все они объединены одной целью: обеспечить соответствие системы состоянию, описанному в сценариях.

Преимущества конфигурационного управления сервера

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

• Быстрое добавление и запуск новых серверов. Когда возникает необходимость развернуть новый сервер, инструмент управления конфигурацией может выполнить большинство основных задач автоматически. Автоматизация может значительно ускорить и улучшить развёртывание сервера; инструменты автоматизации выполняют любой процесс развёртывания быстрее и точнее, чем администратор. К примеру, развёртывание веб-сервер вручную (даже с хорошей документацией) может занять несколько часов, а инструмент делает это за несколько минут.
• Быстрое восстановление. Когда сервер по неизвестным причинам отключается, на полный аудит системы и выяснение этих причин может уйти несколько часов. Благодаря быстрому развертыванию серверов система может автоматически развернуть запасной сервер, который будет поддерживать все сервисы, пока восстанавливается поврежденный сервер.
• Простота. На первый взгляд, администрирование системы вручную кажется очень простой задачей. Однако со временем администратору становится всё труднее запоминать все программы, установленные на сервер, и все внесённые изменения. Устранение неполадок, тонкая настройка и обновление программного обеспечения делает сервер настолько уникальным, что ним трудно управлять и еще труднее воспроизвести. Инструменты управления конфигурациями регистрируют все процедуры, необходимые для развёртывания нового или обновления существующего сервера, в своих сценариях.
• Контроль версий окружения. Переписав окружение сервера в сценарии, вы можете управлять серверным окружением при помощи инструментов и рабочих процессов, которые обычно используют для исходного кода программы. Инструменты контроля версий (например Git) позволяют отслеживать изменения и поддерживать отдельные ветви сценариев. Также с их помощью можно внедрить политику контроля кода. При этом любое изменение будет восприниматься как pull запрос. Это позволяет улучшить консистентность данных инфраструктуры.
• Репликация окружения. Конфигурационное управление позволяет быстро реплицировать окружение, благодаря чему можно создавать многоуровневые экосистемы, в которых будут поддерживаться серверы разработки, тестирования и развёртывания. Это позволяет использовать для разработки локальные виртуальные машины, созданные с помощью одних и тех же скриптов инициализации. Такой механизм позволяет свести к минимуму проблемы, вызванные конфликтом данных разных окружений, что часто происходит при развёртывании одного приложения на разных машинах (с разными операционными системами, версиями программного обеспечения и конфигурациями).

Инструменты управления конфигурациями

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

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

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

• Автоматизация. Каждый инструмент имеет специальный синтаксис и набор функций для написания сценариев автоматизации. Язык большинства инструментов похож на несколько упрощённый язык программирования. Для создания более универсальных скриптов инициализации можно использовать переменные, циклы и условные выражения.
• Идемпотентность. Средства управления конфигурацией отслеживают состояние ресурсов, чтобы избежать повторения задач, которые были выполнены ранее. К примеру, если пакет уже был установлен, инструмент не будет пытаться установить его снова. Суть состоит в том, что после каждого запуска развёртывания система достигает необходимого состояния (или сохраняет его), даже если вы запускаете его несколько раз. Это и есть идемпотентное поведение (его можно применять опционально).
• Подробные данные о системе. Средства конфигурационного управления предоставляют подробную информацию о системе, с которой они работают. Доступ к таким данным можно получить с помощью глобальных переменных – так называемых фактов. Они включают в себя сетевые интерфейсы, IP-адреса, операционные системы, распределение и многое другое. Каждый инструмент предоставляет индивидуальный набор фактов. Их можно использовать для создания универсальных и адаптивных сценариев и шаблонов, которые можно применить в нескольких системах.
• Система шаблонов. Большинство инструментов управления конфигурациями предоставляет встроенную систему шаблонов, которые можно использовать для быстрого создания конфигурационных файлов и сервисов. Шаблоны обычно поддерживают переменные, циклы и условные выражения. Например, шаблоны можно использовать для создания новых виртуальных хостов Apache или для установки серверов. Помимо статических значений, шаблон должен содержать значения, индивидуальные для каждого хоста (например NameServer и DocumentRoot).
• Расширяемость. Любой сценарий для управления конфигурацией можно индивидуализировать, подогнать под самые строгие требования и нужды конкретного сервера. Однако часто возникает необходимость использовать одни и те же конфигурации (или их часть) на нескольких серверах. Большинство средств управления конфигурацией предоставляет возможность повторно использовать фрагменты сценариев в качестве модулей и плагинов.

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

Как выбрать инструмент управления конфигурациями

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

Сложность инфраструктуры

Большинство инструментов управления конфигурациями требуют минимальной иерархии, состоящей из ноды и контроллера, который будет управлять ею. К примеру, для работы Puppet на каждую ноду нужно установить агент, а на контроллер – приложение мастера. Ansible реализует децентрализованную модель управления, для этого не нужно устанавливать дополнительного ПО на ноды; однако для выполнения задач необходим постоянный доступ SSH. В маленьких проектах лучше использовать упрощённую инфраструктуру, но при этом важно учитывать такие аспекты как масштабируемость и безопасность.

Некоторые инструменты могут состоять из большего числа компонентов, а это может усложнить инфраструктуру и увеличить общую стоимость развёртывания.

Стоимость

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

Продвинутые функции

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

Сообщества и поддержка

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

Краткий обзор популярных инструментов

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

	Ansible	Puppet	Chef
Язык сценариев	YAML	DSL на основе Ruby	Ruby
Инфраструктура	Контроллер, управляющий нодами через SSH	Puppet Master синхронизирует конфигурации на нодах (Puppet Node)	Рабочая станция Chef передаёт конфигурации на Chef Server, который в свою очередь обновляет данные на нодах.
Специальное ПО для нод	Нет	Да	Да
Централизованное управление	Нет; по сути, любая машина может быть контроллером.	Да (Puppet Master)	Да (Chef Server)
Терминология сценариев	Playbook / роли	Манифесты/модули	Рецепты/кукбуки
Выполнение задач	Последовательное	Непоследовательное	Последовательное

Заключение

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

Tags: ,