Цикл статей по основам Software Configuration Management
Пролог
Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной 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 (см. ссылки в конце), там это рассматривается много и плодотворно. Правда, не всегда понятно и почти всегда – сухо и скучно.
Для начала — достаточно. Следующая часть будет посвящено тому, как же определяются продукты и конфигурации, которыми мы будем управлять. Также коснусь вопроса о компонентной разработке, продуктовых линейках и их связи с СМ.
Источник
Конфигурация программного обеспечения
- Конфигурация программного обеспечения — совокупность настроек программы, задаваемая пользователем, а также процесс изменения этих настроек в соответствии с нуждами пользователя.
Существуют различные подходы к хранению конфигурации. Многие программы хранят настройки в текстовых файлах, что особенно характерно для UNIX-подобных ОС. В ОС Windows текстовые конфигурационные файлы также используются и часто имеют формат .ini. Несмотря на то, что почти во всех случаях эти файлы можно изменять вручную, во многих случаях для этого создаётся специальный интерфейс (который может быть как консольным, так и графическим).
Иногда в UNIX-подобных ОС конфигурация задаётся на этапе сборки программы, и для её изменения программу необходимо пересобирать. Ярким примером может служить ядро Linux. Почти для всех программ, собираемых с использованием сценариев autoconf, можно подключать или отключать те или иные внешние библиотеки, указывая параметры для сценария configure.
Часто для хранения конфигурации используется специальная база данных. В ОС Windows используется реестр Windows, а в среде рабочего стола GNOME — демон GConf; в обоих случаях конфигурация имеет древовидную структуру.
Связанные понятия
О программном обеспечении рассказывает другая статья.Переносимое приложение (также портативное, автономное, и — неточно, в качестве кальки — портированное; англ. portable application, portable app) — программное обеспечение, которое для своего запуска не требует процедуры установки и может полностью храниться на съёмных носителях информации, что позволяет использовать данное ПО на многих компьютерах. Переносимое приложение может быть настроено так, чтобы считывать свои конфигурационные настройки.
Жёсткой ссылкой (англ. hard link) в UFS-совместимых файловых системах называется структурная составляющая файла — описывающий его элемент каталога.
Источник
Способ установки и конфигурирования программного обеспечения
Владельцы патента RU 2260839:
Изобретение относится к области приборостроения. Его использование для установки и настройки программного обеспечения современных цифровых вычислительных машин позволяет обеспечить возможность объективного контроля над процессом выполнения инсталляции программного продукта в установочных пакетах, что повышает надежность инсталляции и обеспечивает безотказность процесса установки сложных программных систем. Этот технический результат достигается тем, что одна или несколько операций в каждом установочном пакете объединяются согласно логике функционирования в фазу, которой присваивается один или несколько атрибутов; каждая фаза установочного пакета выбирается, идентифицируется и помечается; при этом, если очередная фаза помечена как обработанная, осуществляется переход к следующей фазе, в противном случае осуществляется вызов очередной фазы в каждом вложенном установочном пакете; при этом, если текущая фаза найдена в одном из установочных пакетов, то в нем последовательно выбираются, анализируются и идентифицируются все фазы, расположенные до найденной, и сама найденная фаза, каждая из которых после обработки помечается как обработанная. 1 з.п. ф-лы.
Данное предложение относится к области приборостроения и может быть использовано в программных системах установки и настройки программного обеспечения современных цифровых вычислительных машин с воздействием на порядок выполняемых операций.
Способы установки и конфигурирования программного обеспечения известны [1]. Эти способы реализованы в современных цифровых вычислительных машинах в виде программ инсталляции, которые выполняют копирование файлов программного обеспечения на компьютер назначения, а также запись параметров конфигурации и другие действия по настройке программного обеспечения. Последовательность технологических операций в известных способах установки и конфигурации программного обеспечения должна строго выполняться в порядке, заданном разработчиком программы инсталляции. Наиболее современной программой инсталляции является Windows Installer — составная часть технологии IntelliMirror, используемая для работы с приложениями Windows 200 [2]. С ее помощью упрощается установка приложений и их обновление, устраняется возможность «конфликта версий», появляются дополнительные возможности по управлению программами, установленными в системе. Программа инсталляции [2] состоит из главного установочного пакета и связанных с ним установочных пакетов. В свою очередь каждый установочный пакет состоит из одной или нескольких операций, объединенных согласно логике функционирования установочного пакета. Установочный пакет может содержать ссылки на другие установочные пакеты. При этом при выполнении установки и конфигурирования программного обеспечения могут быть использованы не все операции каждого установочного пакета, а только их произвольная выборка, определяемая целями и составом программного обеспечения, а также конфигурацией технических средств. Способ установки и конфигурирования программного обеспечения [2] требует выполнения установочных операций в составе этих пакетов в строгой последовательности, заданной разработчиком. С целью оптимизации инсталляционных процессов внутри каждого установочного продукта к каждому параметру установки может быть назначен весовой коэффициент [3]. Каждый весовой коэффициент в комбинации с состоянием параметров инсталляции, информацией о разбиении потенциальных компьютеров назначения используется в процедуре выбора для каждой потенциально возможной компьютерной системы назначения соответствующего пакета установочных пакетов.
Способ установки и конфигурирования программного обеспечения [3] является одним из самых совершенных и наиболее близких к заявляемому способу. Каждый установочный пакет, составляющий программную систему установки и настройки программного обеспечения по способу [3], разрабатывается независимо от других пакетов и может впоследствии быть использован в других программах инсталляции в комбинации с иными установочными пакетами без каких-либо модификаций. Поэтому, во-первых, в рамках каждого установочного пакета задается абсолютный порядок выполнения всех действий, а выполнение установочных пакетов начинается с главного установочного пакета методом последовательного перебора. Во-вторых, возможно наличие однотипных действий в двух или более установочных пакетах. Следовательно, в процессе установки и настройки программного обеспечения однотипные действия будут выполняться такое число раз, в скольких установочных пакетах они повторяются. Это существенно затрудняет осуществление объективного контроля над последовательностью выполнения действий в установочных пакетах, это снижает надежность, делает невозможным процесс установки сложных программных систем.
Цель данного предложения состоит в обеспечении возможности объективного контроля над процессом выполнения инсталляции программного продукта в установочных пакетах, что повышает надежность инсталляции и обеспечивает безотказность процесса установки сложных программных систем.
Поставленная цель достигается тем, что одна или несколько операций в каждом установочном пакете объединяются согласно логике функционирования данного установочного пакета в фазу, которой присваивается один или несколько атрибутов. После загрузки главного установочного пакета обрабатываются все его фазы методом последовательного перебора. Каждая обработанная фаза помечается как обработанная. При этом во всех установочных пакетах, связанных с главным, осуществляется поиск фазы с идентификатором, равным идентификатору обрабатываемой фазы главного установочного пакета. Если в одном из установочных пакетов такая фаза обнаружена, то обрабатывается каждая непомеченная фаза, предшествующая обнаруженной в этом установочном пакете. При этом обработка каждой фазы обязательно включает поиск во всех установочных пакетах фазы с идентификатором, идентичным идентификатору обрабатываемой в данный момент фазы. После завершения поиска и возвращения в исходную фазу все обработанные фазы помечаются как обработанные. Аналогичным образом после завершения перебора фаз главного установочного пакета последовательно перебираются непомеченные фазы каждого из остальных установочных пакетов. Благодаря такому способу установки и конфигурирования программного обеспечения обеспечивается возможность по помеченным фазам осуществить объективный контроль над последовательностью выполнения фаз в комплектах установочных пакетов, что повышает надежность инсталляции и обеспечивает безотказность процесса установки сложных программных систем.
Сущность способа установки и конфигурирования программного обеспечения состоит в следующем. Вначале осуществляется выделение и загрузка установочных пакетов, начиная с главного установочного пакета. В каждом из загруженных установочных пакетов согласно логике функционирования установочного пакета выделяется одна или несколько операций, которым присваивается один или несколько атрибутов. Кроме того, в каждом установочном пакете одному или нескольким значениям одного или нескольких параметров установки присваивается вес. Эти параметры установки должны быть связаны с процессом установки и конфигурирования установочного пакета. Затем определяется множество компьютеров назначения, на которых может быть осуществлена установка данного установочного пакета. После чего задается процедура вычисления каждого установочного параметра и осуществляется разбиение множества компьютеров назначения на подмножества. При разбиении используются заданные веса в комбинации с состоянием параметров установки и вычисляется критерий соответствия каждого параметра установки для каждой из потенциальных систем компьютеров назначения с целью их дальнейшего конфигурирования. В процессе загрузки главного установочного пакета методом последовательного перебора обрабатываются все его фазы, начиная с начальной. После окончания обработки каждой фазы, то есть после окончания выполнения логически объединенных одной или нескольких операций, эта фаза помечается как обработанная. Факт обработки данной фазы может быть отображен визуально на мониторе. Одновременно с постановкой метки на обработанной фазе во всех остальных установочных пакетах, связанных с главным, осуществляется поиск фазы с атрибутами, соответствующими атрибутам данной обработанной фазы. Если в одном из установочных пакетов фаза с такими атрибутами обнаружена, то начинают обрабатываться фазы этого установочного пакета, которые, во-первых, не помечены; во-вторых, предшествуют найденной в этом установочном пакете фазе. Обработка фаз этого установочного пакета заканчивается на первоначально обнаруженной фазе с идентичными атрибутами. После возвращения в исходную фазу все обработанные фазы помечаются как обработанные. При этом обработка каждой фазы в каждом установочном пакете обязательно включает поиск фаз с аналогичными атрибутами во всех установочных пакетах. После завершения перебора фаз главного установочного пакета последовательно перебираются непомеченные фазы каждого из остальных установочных пакетов. Благодаря тому, что все обработанные фазы наряду с атрибутами имеют проставленные метки, заявляемый способ установки и конфигурирования программного обеспечения представляет возможность контролировать ход инсталляции программного продукта и наблюдать за его ходом с помощью любого устройства отображения. Группирование серии идентичных, одной или нескольких, операций вокруг фазы с общим для всех них набором атрибутов позволяет повысить надежность инсталляции программного продукта, что способно обеспечить безотказность процесса установки и конфигурирования сложных программных систем.
При формулировании существа изобретения были использованы следующие патентные, научно-технические источники:
1. Андреев А.Г. и др. Microsoft Windows 2000 Server и Professional / Под общим редактированием Чекмарева А.Н. и Вишнякова Д.Б. — СПб: БХВ — Санкт-Петербург, 2000 — 992 с.: стр 145, 373.
2. Integrates with Microsoft. Visual Studio. Net Help. 1992-2003. Microsoft Corporation. 0103 Part № X 09-19409, 19410, 19411.
3. Патент США №2003/0163807, М.Кл. G 06 F 009/445, зарегистрирован 27 февраля 2002 г., опубликован 28 августа 2003 г.
1. Способ установки и конфигурирования программного обеспечения, включающий выделение и загрузку установочных пакетов, начиная с главного, назначение в каждом установочном пакете веса каждому одному или более чем одному выбранному значению одного или нескольких параметров установки, связанных с установкой и конфигурацией установочного пакета программного обеспечения, определение множества компьютеров назначения, на которых может быть осуществлена установка установочного пакета программного обеспечения, определение процедуры вычисления каждого из параметров установки, разбиение множества компьютеров назначения в соответствии с каждым параметром установки с использованием назначенных весов в комбинации с состоянием параметров установки, вычисление соответствия каждого параметра установки для каждой из потенциальных систем компьютеров назначения, отличающийся тем, что одна или несколько операций в каждом установочном пакете объединяются согласно логике функционирования установочного пакета в фазу, которой присваивается один или несколько атрибутов, последовательно выбирается, анализируется, идентифицируется и помечается меткой каждая очередная фаза текущего установочного пакета, при этом, если очередная фаза загруженного установочного пакета помечена как обработанная, осуществляется переход к следующей фазе загруженного установочного пакета, а если очередная фаза загруженного установочного пакета не помечена как обработанная, то осуществляется вызов очередной фазы в каждом вложенном установочном пакете, при этом если очередная фаза не имеет вызовов в каждый вложенный установочный пакет, то ее идентификатор заносится в абсолютную последовательность выполнения фаз, а если текущая фаза найдена в одном из установочных пакетов, то в нем последовательно выбираются, анализируются и идентифицируются все фазы, расположенные до найденной, и сама найденная фаза, каждая из которых после обработки помечается меткой как обработанная.
2. Способ установки и конфигурирования программного обеспечения по п. 1, отличающийся тем, что идентификация каждой фазы каждого установочного пакета осуществляется по одному или нескольким атрибутам, присвоенным каждой фазе.
Источник
