Аннотация: Понятие конфигурационного управления. Управление версиями. Понятие "ветки" проекта. Управление сборками. Средства версионного контроля. Единицы конфигурационного управления. Понятие 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) – управленческая технология, связанная с разработкой, выпуском и поддержкой ЖЦ сложных изделий, производимых во многих вариантах, в том числе – по конкретным требованиям заказчика.

При электронном проектировании средствами систем CAE/CAD/CAM должны использоваться и электронные средства управления конфигурацией, отвечающие, в частности, требованиям стандарта ИСО 10303-203.

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

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

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

Эта технология предполагает выполнение следующих операций (по ИСО 10007):

· идентификацию конфигурации, т. е. присвоение ее текущей версии определенного «имени» (кодового обозначения);

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

· учет статуса конфигурации;

· проверку (аудит) конфигурации.

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

В некоторых PDM были предусмотрены следующие статусы для версий документов: рабочий – версия c таким статусом находится в работе, ее можно модифицировать; принятый – именно версия с этим статусом является основой для взаимодействия частей проекта, она служит для обмена данными между объектами, ее модификации осуществляются через рабочий статус; архивный – статус, присваиваемый предыдущим сохраняемым версиям; порождаемый – статус зарезервирован для вновь создаваемых объектов, например при синтезе проектных решений. Разработчик сам изменяет статус объектов.

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

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

Документация конфигурации (ДК, configuration documentation – CD): документация, позволяющая определить и идентифицировать функциональные, физические и эксплуатационные характеристики изделия. В качестве документации конфигурации (ДК) принято рассматривать технические требования (условия), чертежи изделия или электронные данные аналогичного назначения.

Базовая конфигурация (baseline): утвержденная в установленном порядке документация конфигурации.

Концепция изделия (КИ, Product Concept – PC): понятие, описывающее класс подобных изделий, которые предприятие предлагает заказчикам. КИ – идея изделия, отвечающая заданному набору технических требований (Specification), требованиям заказчиков («Облик изделия» или «Лицо изделия»). С точки зрения заказчика концепция изделия представляет обозначение формализованного набора требований (Specification), отражающих потребности заказчика. С точки зрения производителя концепция изделия – это обозначение семейства модификаций изделия, поставляемых на рынок.

В стандарте ИСО 10303, спецификации SPS и модели NPDM понятию объект управления конфигурацией (Объект конфигурации (ОК) – Configuration Item – CI) соответствует любое техническое или программное средство (или их комбинация), выполняющее конечную функцию (или некоторую функцию конечного изделия), выделенное для целей управления конфигурацией и обладающее определенным набором свойств (характеристик). Один объект конфигурации может входить в другой и, в свою очередь, включать в себя другие объекты конфигурации. Конфигурация в целом и составляющие ее ОК могут быть соответствующим образом документированы и утверждены. ОК обычно обозначают уникальным буквенно-цифровым идентификатором (кодом), который используется также в качестве неизменяемой части для серийных номеров и уникальной идентификации отдельных компонентов (блоков) этого ОК.

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

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

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

В общем виде управление конфигурацией согласно ИСО 10007 включает в себя 4 основных этапа, связанных с выполнением предпроектных работ, проектированием, производством и эксплуатацией (рис. 6.5).

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

· формализацию требований;

· структурирование требований;

· проверку требований на выполнимость и непротиворечивость;

· управление изменениями в требованиях.

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

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

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

Выделим две основные задачи в конфигурационном управлении:

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

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

Эта процедура является мощным средством интеграции проекта, основой итеративной разработки.

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

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

Пользовательская документация;

Проектная документация;

Исходные тексты ПО;

Пакеты тестов;

Инсталляционные пакеты ПО;

Тестовые отчеты.

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

Структура – набор файлов.

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

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

Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ. Есть не у всех элементов, например, может не быть у документации, тестовых пакетов.

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

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

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

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

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

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

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

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

Отличаются параметры компиляции.

Несоответствие друг другу различных частей проекта;

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

В связи с этим процедуру сборки проекта часто автоматизируют, то есть выполняют не из среды разработки, а из специального скирпта – build-скрипта. Этот скрипт используется тогда, когда разработчику требуется полная сборка всего проекта. А также он используется в процедуре непрерывной интеграции (continuesintegration) – то есть регулярной сборке всего проекта (как правило – каждую ночь).

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

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

Понятие baseline

Baseline – это базовая, последняя целостная версия некоторого продукта разработки, например, документации, программного кода и т.д.

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

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

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

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

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

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

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

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

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

Конфигурационная единица (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[

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