что называют программной конфигурацией
Конфигурация программного обеспечения
Конфигурация программного обеспечения — совокупность настроек программы, задаваемая пользователем.
Часто для хранения конфигурации используется специальная база данных. В Windows используется реестр Windows, а в GNOME — GConf; в обоих случаях конфигурация имеет древовидную структуру.
Источники
Полезное
Смотреть что такое «Конфигурация программного обеспечения» в других словарях:
Перечень школьного программного обеспечения — Содержание 1 Бразилия 2 Великобритания 3 Индия … Википедия
Конфигурация — Конфигурация: В Викисловаре есть статья «конфигурация» Конфигурация (астрономия) … Википедия
Конфигурация компьютера — В области информационных и компьютерных систем под конфигурацией понимают определенный набор комплектующих, исходя из их предназначения, номера и основных характеристик. Зачастую конфигурация означает выбор аппаратного и программного обеспечения … Википедия
Конфигурация (ПО) — У этого термина существуют и другие значения, см. Конфигурация. Совокупность параметров программного обеспечения. В операционных системах *NIX изменение конфигурации производится путем редактирования текстовых файлов настройки, расположенных, как … Википедия
ГОСТ Р МЭК 61508-4-2007: Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения — Терминология ГОСТ Р МЭК 61508 4 2007: Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения оригинал документа: 3.7.4 анализ влияния (impact analysis) … Словарь-справочник терминов нормативно-технической документации
Инфраструктура — (Infrastructure) Инфраструктура это комплекс взаимосвязанных обслуживающих структур или объектов Транспортная, социальная, дорожная, рыночная, инновационная инфраструктуры, их развитие и элементы Содержание >>>>>>>> … Энциклопедия инвестора
система — 4.48 система (system): Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей. Примечание 1 Система может рассматриваться как продукт или предоставляемые им услуги. Примечание 2 На практике… … Словарь-справочник терминов нормативно-технической документации
СТО Газпром 2-2.3-141-2007: Энергохозяйство ОАО «Газпром». Термины и определения — Терминология СТО Газпром 2 2.3 141 2007: Энергохозяйство ОАО «Газпром». Термины и определения: 3.1.31 абонент энергоснабжающей организации : Потребитель электрической энергии (тепла), энергоустановки которого присоединены к сетям… … Словарь-справочник терминов нормативно-технической документации
Р 50.1.048-2004: Информационно-телекоммуникационные игровые системы. Термины и определения — Терминология Р 50.1.048 2004: Информационно телекоммуникационные игровые системы. Термины и определения: 2.3.25 адаптивное сопровождение: Изменение программного продукта после поставки, обеспечивающее его работоспособное состояние в измененных… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р МЭК 61513-2011: Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования — Терминология ГОСТ Р МЭК 61513 2011: Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования оригинал документа: [МАГАТЭ 50 SG D8] Примечание 1 См. также «система, важная для безопасности», «класс систем контроля… … Словарь-справочник терминов нормативно-технической документации
Большая Энциклопедия Нефти и Газа
Программная конфигурация
Программная конфигурация и база данных хранятся в энергонезависимом ОЗУ модулей. [1]
Совокупность программ, установленных на компьютере, называется его программной конфигурацией : Совокупность оборудования, подключенного к компьютеру, называется его аппаратной конфигурацией. Несмотря на то что по своей архитектуре и функциональному назначению разные компьютеры могут быть весьма близки друг другу, найти два компьютера, имеющих одинаковые аппаратные и программные конфигурации, практически невозможно. На каждом рабочем месте программно-аппаратная конфигурация создается такой, чтобы наиболее эффективно решать конкретные практические задачи, характерные для данного рабочего места. [3]
Недостатком механизма восстановления являются значительные затраты дискового пространства на хранение контрольных точек. Если аппаратная или программная конфигурация компьютера подвержена регулярным изменениям, то объем дискового пространства, Используемый для хранения данных контрольных точек, может выйти за любые разумные пределы. В этом случае средство Восстановление системы можно отключить, отдавая себе отчет, что надежность работы компьютера в этом случае может снизиться. [5]
В ЕС ЭВМ имеются МПД с жесткой и программной конфигурацией ( прил. Создание сложных систем телеобработки связано с возможностями перераспределения функций управления между центральной ЭВМ и периферийными процессорами телеобработки данных. [7]
Рассмотрим вначале большую автономную систему. Хотя интерес представляют и малые системы, но общую операционную и программную конфигурацию большой системы можно использовать как эталон для сравнения менее сложных конфигураций. В большой системе имеется набор готовых программ, которые обычно поставляются вместе с ЭВМ. Этот набор обычно включает операционную систему, самонастраивающий загрузчик, ассемблер, один или несколько компиляторов или интерпретаторов, редактор связей, загрузчик, системные подпрограммы и макрокоманды, а также множество подпрограмм управления ВВ. [9]
Это комплексы программ Netscape Communicator, Irbis и Microsoft Office, программа Adobe Acrobat Reader и другие. Уже во время разработки программных конфигураций рабочих станций стало очевидно, что установка всех этих приложений на каждой из рабочих станций будет крайне неэффективна. Не говоря уже о том, что целесообразность такого решения при наличии корпоративной сети вообще представляется весьма сомнительной, это повлекло бы резкое увеличение размера образа рабочей станции, а также усложнило бы жизнь службе технической поддержки. Поэтому на основе службы Novell Zen Works Application Management была построена эффективная система управления приложениями, решившая многие проблемы обеспечения доступа пользователей к необходимым программам и сохранения целостности этих программ. [12]
Что называют программной конфигурацией
Состав вычислительной системы называют конфигурацией. Конфигурация вычислительной системы включает аппаратные и программные средства, которые представляют собой отдельно аппаратную конфигурацию и программную конфигурацию.
3.1. Аппаратная конфигурация вычислительной системы
Современные компьютеры и вычислительные комплексы имеют блочно-модульную конструкцию – аппаратную конфигурацию, необходимую для исполнения конкретных видов работ, которую можно собирать из готовых блоков и узлов. По способу расположения устройств различают внутренние и внешние устройства. Внешними, как правило, являются большинство устройств ввода-вывода данных и некоторые устройства, предназначенные для длительного хранения данных.
Согласование между отдельными узлами и блоками выполняют с помощью аппаратных интерфейсов.
Аппаратными интерфейсами называют переходные аппаратно-логические устройства.
Стандарты на аппаратные интерфейсы называют протоколами.
Протокол – это совокупность технических условий, обеспечивающих взаимное согласование различных устройств при их совместной работе.
Многочисленные интерфейсы, присутствующие в любой вычислительной системе, можно условно разделить на последовательные и параллельные. Через последовательные интерфейсы данные предаются последовательно бит за битом, а через параллельные – одновременно группами битов. При этом количество битов, участвующих в одной посылке, определяется разрядностью интерфейса (8, 16, 24, 32, 64-разрядные).
Поскольку обмен данными через последовательные интерфейсы производится битами, их производительность измеряют битами в секунду (бит/с, Кбит/с, Мбит/с). Последовательные интерфейсы применяют для подключения “медленных” устройств, когда нет существенных ограничений на продолжительность обмена данными.
Так как обмен данными через параллельные интерфейсы производится группами битов (байтами), то их производительность измеряется байтами в секунду (байт/с, Кбайт/с, Мбайт/с). Параллельные интерфейсы применяют для подключения быстродействующих устройств там, где важна скорость передачи данных.
3.2. Базовая аппаратная конфигурация компьютера
Компьютер – это электронный прибор (универсальная техническая система), предназначенный для автоматизации создания, хранения, обработки и транспортировки данных.
Конфигурацию компьютера (состав оборудования) можно гибко изменять по мере необходимости. Однако существует понятие базовой конфигурации, которую считают типовой. Понятие базовой конфигурации по мере развития техники может меняться. В настоящее время в состав базовой конфигурации включают: системный блок, монитор, клавиатуру и мышь.
Системный блок является основным узлом, внутри которого установлены наиболее важные компоненты:
Монитор – устройство визуального представления данных. Его основными потребительскими параметрами являются: размер и шаг маски экрана, максимальная частота регенерации изображения, класс защиты. Стандартные размеры мониторов 14,15, 17, 19, 20 и 21 дюймов. Маска – это панель с регулярно расположенными отверстиями или щелями, которая расположена перед люминофором. Шаг маски – это расстояние между отверстиями или щелями. Чем меньше шаг маски, тем чётче и точнее изображение. В современных мониторах шаг маски составляет 0,25 – 0,27 мм. Частота регенерации (обновления) изображения показывает, сколько раз в течение секунды монитор может полностью сменить изображение. В настоящее время минимальная величина частоты регенерации составляет 75 Гц, нормальная – 85 Гц и комфортная – 100 и более Гц. Класс защиты монитора определяется стандартом, которому соответствует монитор с точки зрения требований техники безопасности. В настоящее время самые жёсткие нормы по параметрам, определяющим качество изображения (яркость, контрастность, мерцание, антибликовые свойства покрытия) установлены в стандарте ТСО-99.
Клавиатура – клавишное устройство управления компьютером. Служит для ввода алфавитно-цифровых (знаковых) данных, а также команд управления. Комбинация монитора и клавиатуры обеспечивает простейший интерфейс (взаимодействие) пользователя. С помощью клавиатуры управляют компьютерной системой, а с помощью монитора получают от неё отклик.
Мышь – устройство управления манипуляторного типа. Перемещение мыши по плоской поверхности синхронизировано с перемещением графического объекта (указателя мыши) на экране монитора. Работу мыши обеспечивает специальная системная программа – драйвер мыши. Драйвер мыши предназначен для интерпретации сигналов, поступающих через порт, и обеспечивает механизм передачи информации о положении и состоянии мыши операционной системе и работающим программам. Комбинация монитора и мыши обеспечивает наиболее современный тип интерфейса пользователя.
Кроме базовой конфигурации компьютера в его состав могут входить и периферийные устройства. Периферийные устройства компьютера подключаются к его интерфейсам и предназначены для выполнения вспомогательных операций. Благодаря периферийным устройствам, компьютерная система приобретает гибкость и универсальность.
Классификация периферийных устройств по назначению.
3.3. Программная конфигурация вычислительной системы
Программа – это упорядоченная последовательность команд. Конечная цель любой компьютерной программы – управление аппаратными средствами. Программное и аппаратное обеспечение в компьютере работают в неразрывной связи и в непрерывном взаимодействии. Состав программного обеспечения вычислительной системы называют программной конфигурацией. В программной конфигурации между её программами существует взаимосвязь, то есть имеет место межпрограммный интерфейс. Возможность существования такого интерфейса основана на существовании технических условий и протоколов взаимодействия. На практике межпрограммный интерфейс (взаимодействие) обеспечивается путём распределения программного обеспечения по нескольким взаимодействующим между собой уровням. Эти уровни представляют собой пирамидальную конструкцию. Каждый следующий уровень опирается на программное обеспечение предшествующих уровней. Уровни программного обеспечения подразделяются на: базовый, системный, служебный и прикладной уровни.
Базовый уровень – самый низкий уровень программного обеспечения представляет базовое программное обеспечение. Оно отвечает за взаимодействие с базовыми аппаратными средствами и, как правило, программные средства входят непосредственно в состав базового оборудования и хранятся в специальных микросхемах ПЗУ. Программы и данные записываются в микросхемы ПЗУ на этапе производства и не могут быть изменены в процессе эксплуатации.
Системный уровень – переходной. Программы, работающие на этом уровне, обеспечивают взаимодействие прочих программ компьютерной системы с программами базового уровня и непосредственно с аппаратным обеспечением, то есть выполняют “посреднические” функции. Конкретные программы, отвечающие за взаимодействие с конкретными устройствами, называются драйверами устройств. Они входят в состав программного обеспечения системного уровня. Программы, отвечающие за взаимодействие с пользователем, называют средствами обеспечения пользовательского интерфейса. Совокупность программного обеспечения системного уровня образует ядро операционной системы компьютера. Если компьютер оснащён программным обеспечением системного уровня, то он уже подготовлен к установке программ более высоких уровней, к взаимодействию программных средств с оборудованием и с пользователем. Наличие ядра операционной системы – непременное условие для возможности практической работы человека с вычислительной системой.
Служебный уровень – это служебные программы, обеспечивающие взаимодействие с программами базового и системного уровней. Служебные программы (утилиты) предназначены для автоматизации работ по проверке, наладке и настройке компьютерной системы.
Классификация служебных программ
Прикладной уровень – комплекс прикладных программ, с помощью которых на рабочем месте обеспечивается выполнение конкретных задач.
Классификация прикладных программ:
3.4. Локальные и глобальны компьютерные сети
При соединении двух и более компьютеров образуется компьютерная сеть. Для создания компьютерных сетей необходимо специальное аппаратное обеспечение (сетевое оборудование) и программное обеспечение (сетевые программные средства).
В соответствии с используемыми протоколами компьютерные сети подразделяются на локальны и глобальные.
В локальных компьютерных сетях преимущественно используется единый комплект протоколов для всех участников. По территориальному признаку локальные сети отличаются компактностью. Они могут объединять компьютеры одного помещения, этажа, здания, группы компактно расположенных сооружений. Создание локальных сетей характерно для отдельных предприятий или отдельных подразделений предприятий.
Глобальные сети имеют, как правило, увеличенные географические размеры. Они могут объединять как отдельные компьютеры, так и отдельные локальные сети, в том числе и использующие различные протоколы. Создание глобальных сетей характерно для предприятия или отрасли занимающих обширную территорию. В этом случае в одну глобальную сеть могут объединяться отдельные локальные сети. Такие локальные сети связывают между собой с помощью традиционных каналов связи (кабельных, радиорелейных, спутниковых). Для связи между собой нескольких локальных сетей, работающих по разным протоколам, служат специальные средства, называемые шлюзами. При подключении локальной сети предприятия к глобальной сети важную роль играет сетевая безопасность. К числу мер безопасности относятся:
Предназначение всех видов компьютерных сетей определяется двумя функциями:
В модели ISO / OSI обмен данными между удалёнными клиентами сети происходит:
На компьютере получателя информации происходит обратный процесс преобразования данных от битовых сигналов до документа.
Software Configuration Management // Конфигурации и baselines
Итак, по горячим следам продолжаю публиковать материалы, касающиеся основ управления конфигурацией программных средств. Прочитайте предыдущую заметку, если вдруг пропустили.
Ниже речь пойдет о следующих вещах:
— Рабочие продукты и конфигурации;
— Компонентная разработка;
— Продуктовые линейки;
— Стабилизация результатов работы;
— Baselines AKA базовые конфигурации;
— Конфигурации при компонентной разработке;
— Конфигурации при наличии продуктовых линеек.
Рабочие продукты и конфигурации
Что же будет являться рабочими продуктами в рамках проекта? Понятно, что для маркетинга и менеджмента продукт будет ровно один – тот, за который компания получит деньги. Ну, или несколько, по числу видов коробок, выдаваемых на рынок. Нас же интересует «нижний уровень» – то, чем будут оперировать постановщики задач, разработчики, тестеры и вообще каждый участник проекта. Задача CM – определить множество тех элементов, которые будут создаваться и изменяться командой. На этом этапе появляется понятие «configuration item» («элемент конфигурации») – это атомарный элемент, которым наиболее удобно управлять в рамках разработки. В дальнейшем будем называть его просто «CI».
К объектам, попадающим под действие CM, относятся и любые объекты, поставляемые вовне (инсталяторы, маркетинговые материалы и т.п.). Хоть их и можно получить из перечисленных выше рабочих продуктов, но конечный продукт, выдаваемый пользователю, также нуждается в идентификации.
Компонентная разработка и продуктовые линейки
Как же эти элементы конфигурации, атомарные единицы учета, организуются внутри проекта?
Складываются они вместе согласно архитектуре самого приложения. Ведь разработчики, как правило, стремятся уменьшить сложность производимых систем. С этой целью они раскладывают создаваемое на взаимосвязанные части – классы, компоненты, библиотеки, подсистемы и т.п. Упростим терминологию и в дальнейшем любые составные части создаваемых систем будем называть компонентами. CM же берёт эту организацию за основу и структурирует рабочие продукты соответствующим образом с помощью своих инструментов и политик.
Компоненты становятся новыми элементами конфигурации. Они становятся самостоятельными рабочими единицами, так же подлежащими единому контролю. Кроме того, они могут устанавливать даже собственный процесс разработки. CM’ные практики в этом случае нужны для того, чтобы эти отдельные блоки контролировать самостоятельным образом, получать промежуточные версии, стабилизировать и выпускать для интеграции в продукт более высокого уровня.
Итак, создаем систему, строим её из кирпичиков-компонентов. И нередка ситуация, когда одна система поставляется сразу в нескольких вариантах. За примерами далеко ходить не надо, взгляните на варианты поставки «Висты». И зачастую всё отличие разных вариантов/версий/редакций продуктов – всего в одном или нескольких компонентах, а то и вовсе в настройках. Как быть? Для этого создается то, что для простоты дальнейшего изложения будем называть продуктовыми линейками. Продуктовая линейка – это ответвление в истории развития продукта, дающее возможность изменять часть компонент независимо от других подобных ответвлений. (Здесь понятие «продукт» употребляется с маркетинговой точки зрения.)
Всё по теории эволюции – одноклеточное остается одноклеточным, но в результате мутаций и цепи случайностей (или же по злому умыслу) дает жизнь многоклеточным. Была линейка человекообразных приматов – от неё отделилась линейка homo sapience, но начальная порода обезьян продолжила жить своей жизнью. «Компоненты» у каждой «линейки» – почти на 99% совпадают. И только несколько процентов (мозги и ещё кое-что по мелочи) разрабатываются эволюцией независимо от родительской линейки и отличают одни виды от других.
Схема 1. Соотношение компонентов, суперкомпонента и продукта.
На схеме 1 образно показан компонентный состав продукта. 1-8 — это компоненты, 4 — это «суперкомпонент», включающий в себя компоненты 5 и 6. В рамках интеграции продукта работа с ним ведется, как с обычным компонентом.
Схема 2. Соотношение компонент и продуктов при использовании продуктовых линеек.
На схеме 2 показано, как одни и те же компоненты могут быть использованы при работе с продуктовыми линейками. Например, имеется Продукт 1, состоящий из нескольких компонентов и суперкомпонента. На его основе производятся продукты 2 и 3.
Продукт 2 берет все те же компоненты, за исключением 1 и 6 — они исключаются из работы (или игнорированием соответствующих директорий, или выключением директив компиляции). В дополнение, изменяется компонент 3 — он становится 3′ (штрих не проглядите). Также в единственный суперкомпонент добавляется новый компонент за номером 9.
Продукт 3 также берет за основу кодовую базу Продукта 1, однако берет в себя ещё и изменения из Продукта 2 — компоненты 9 и 3′. Также изменениям подвергаются компоненты 7 и 8, которые теперь называются 7′ и 8′ соответственно (да, тоже со штрихами).
Что в итоге? В итоге имеем несколько компонентов, интегрируемых одновременно в два-три разных продукта. Возьмем, к примеру, номер 2 – он неизменен во всех трёх продуктах. Напрашивается вывод – выпустить его один раз и просто «вставить» везде, где потребуют. Так и делается – компонентная команда в лице CM-инженера стабилизирует работу и передает на дальнейшую интеграцию трём «продуктовым» командам. Аналогично поступает CM-команда компонента 3’ – после внесения изменений поверх «предка» 3, полученный релиз компонента 3’ отдается в два продукта.
Причем использование одного компонента в разных продуктах – это не копирование исходников из директорий одного продукта в другой. Нет, смысл заключается именно в том, чтобы выпущенная конфигурация компонента находилась в системе контроля версий и все заинтересованные просто обращались к нему по мере включения в свой код.
В технической плоскости CM является связующим звеном между компонентами и линейками. В управленческой плоскости, где принимаются архитектурные решения, рулят менеджеры, тим-лиды, архитекторы, а всю техническую поддержку этого разделения возлагают на CM-инженеров. Именно они дают конечным разработчикам инструкции («политики») о том, в какие системы контроля складывать свой код, как именно его туда складывать, как регистрировать изменения в системах багтрекинга, каков порядок объединения компонент, что в каком виде давать тестерам и как выпускать продукт заказчику. Сами же продукты становятся новыми элементами конфигурации.
Основной вывод: CM помогает определить, из каких кирпичей мы будем складывать продукт и дает цементный раствор для их скрепления. Какими методами определяет и скрепляет – рассмотрим дальше.
Стабилизация результатов работы
Итак, определили рабочие продукты, компоненты, линейки – пора и за дело браться. Начинается цикл разработки. Работа идет, рабочие продукты появляются, изменяются, создаются новые компоненты, разделяются линейки – жизнь кипит. Как всегда, в определенный момент хочется остановиться, оглянуться назад и понять – в какой точке находится продукт, что и как уже сделано, каковы планы. Для того чтобы получить полную картину, нужно привести разработку к какому-то общему знаменателю. С точки зрения менеджмента это может быть сделано по-разному – можно, например, посмотреть прогресс работ, получить срез метрик и т.п. – и далее принять какое-то решение, касающееся распределения задач.
С точки зрения CM’а это означает, что надо стабилизировать конфигурацию рабочих продуктов. Например, имея команду из 20 человек, нужно взять все наработанные разными людьми куски функциональности – документы, код и друге результаты – и свести их воедино.
Стабилизация конфигурации – это процесс получения новой конфигурации из имеющихся промежуточных конфигураций. Для этого процесса также используются также термины «выпуск», «release» или «релиз». Результат стабилизации также может быть назван, в свою очередь, релизом или выпуском.
Например, есть основная конфигурация – версия продукта 1.0. Есть промежуточная конфигурация – разработанная девелопером новая «фича». Есть также 2 другие конфигурации – поправленные ошибки от двух других разработчиков. Стабилизацией в данном случае будет объединение результатов работы всех трех разработчиков и создание из них новой конфигурации, т.е. набора CI, которые образуют готовый продукт.
Полученная конфигурация проверяется на соответствие требованиям к составляющим её рабочим продуктам. Требования могут быть разнообразными, как правило, это количественные критерии качества. Скажем, в приведенном примере с 3 девелоперами, подобное требование к коду – это успешное прохождение 98% регрессионных тестов. Код от всех разработчиков интегрируется, конфигурация стабилизируется, продукт собирается (например, отстраивается) и отдается на тесты.
Для релиза также делаются release notes. На русский этот термин переводится как «заметки о выпуске» или «дополнительные сведения» – так этот термин звучит в глоссарии Microsoft. Также может быть использовано «описание выпуска».
Если конфигурация соответствует требованиям, предъявляемым к стабильным релизам, то конфигурация считается стабильной. Например, если процент пройденных регрессионных тестов – 98%. По выбору менеджмента или CM-инженера, она становится тем, что называется «baseline».
Базовая конфигурация
Baseline – это конфигурация, выбранная и закрепленная на любом этапе жизненного цикла разработки как основа для дальнейшей работы. Переводом термина могут быть фразы «базовая конфигурация», «базовый уровень», «базовая версия» или «стабильная база». В дальнейшем будет преимущественно использован термин «базовая конфигурация».
Если вернуться обратно к нашему примеру про трёх разработчиков, то там стабилизированная конфигурация прошла оценку качества. То же самое обязательно и при выпуске базовой конфигурации. Менеджмент (тим-лид или SQA) смотрит на показатели качества, а также на другие факторы – например, на результаты инспекций кода или что-то ещё, что может вызвать сомнения. После чего принимает решение о том, что релиз должен быть взят за основу для работы всех остальных разработчиков, быть базой для разработки. Далее CM-инженер выполняет разного рода действия (например, навешивает метку и отстраивает код продукта) и выбранная конфигурация становится базовой. При этом она (как минимум, в виде исходников) выкладывается в открытый для всей команды доступ.
Возможен вариант, когда конфигурация не проходит по критериям качества и вообще не может быть использована для сборки конечного продукта. Например, продукт только начал разрабатываться и готов только код отдельных компонентов, да и у тех – заглушки вместо работающих функций. Нужно сделать конфигурацию основой работы для всей команды, но при этом миновать процедуру релиза – просто потому, что пока нельзя ничего собрать воедино. Такая конфигурация также имеет право быть использованной в качестве базовой, главное — четко обозначить имеющиеся ограничения по использованию в заметках о выпуске.
Любой выпуск базовой конфигурации обязательно снабжается заметками о выпуске. Участник команды, берущий подобную конфигурацию для работы, должен знать – от чего именно он будет отталкиваться в работе. Также надо знать, есть ли в новой конфигурации те новые функции или исправления ошибок, от которых может зависеть его работа. Не лишним будет также знать, нужны ли какие-то специальные процедуры апгрейда его экземпляра системы перед использованием новой базы для разработки. Вся перечисленная информация как раз дается в заметках о выпуске.
Во многих командах результаты интеграционной работы (появляющиеся релизы и базовые конфигурации) выкладываются в специально отведенное место – область релизов, или release area. Организация этой области и поддержание её в актуальном виде – задача CM-инженеров.
Схема 3. Связь конфигураций, релизов и базовых конфигураций.
На Схеме 3 показан небольшой пример появления конфигураций во времени. Начальное состояние проекта – конфигурация 1. Она же является первым базисом, от которого будет идти дальнейшая разработка. Предположим, проект на начальной стадии. Через какое-то время появляется обновленная конфигурация 2. Разработка только началась и мы выпустили релиз, чтобы выдать команде хоть какую-то основу для дальнейшей работы. В ходе проверки выяснилось, что базой для работы этот выпуск служить не может – есть непонятные и противоречивые места.
Для их устранения группы разработки делают доработки. В результате них появляются конфигурации 3 и 4 – оба они разработаны на основе 2, но друг с другом они пока не согласуются, поскольку не включают изменения друг от друга. CM-инженер создает итоговую конфигурацию 5, сделанную на основе 2, 3 и 4. После проверки менеджмент дает отмашку – базовой конфигурации быть! По этому сигналу CM-команда выпускает этот релиз как официальную базовую конфигурацию и разработчики берут уже её за основу.
Далее история повторяется – группа разработки вносит изменения – появляется конфигурация 5. Её, в свою очередь, интегрирует CM-инженер и она получает номер 7. Он также становится официальной базой для разработки.
Конфигурации при компонентной разработке
Аналогичный подход используется и при компонентной разработке. Внутри каждого компонента идет работа, в рабочих продуктах и их элементах конфигурации постоянно появляются изменения, надо их периодически, или же по требованию менеджмента, стабилизировать. Каждый компонент делает это в общем случае самостоятельно и с тем графиком, который требуется именно для него. Поэтому, например, для одной команды стабилизация и выпуск релиза делается 5 раз в неделю, для другой – 1 раз в 2 недели.
Поскольку компоненты объединяются в единое целое, должны существовать отдельные процедуры и ресурсы для подобной системной интеграции. В этом случае работа интеграционной команды вышестоящего компонента или всей системы лишь немногим отличается от работы интеграторов компонентов. Отличается только масштаб, а также, возможно, инструменты и критерии оценки зрелости получаемых релизов.
В частности, после интеграции всей системы нужно не просто пройти регрессионное тестирование каждого входящего компонента. Надо ещё прогнать системные тесты, проверяющие взаимодействие разных частей системы между собой – как правило, это не входит в область тестирования каждой отдельной подсистемы. Кроме того, от CM’ной команды всего продукта может потребоваться сбор дополнительных метрик. Всё это требует больших ресурсов и некоторой доработки политик CM-команды вышестоящего компонента.
Конфигурации продуктовых линеек
Как меняются политики CM в случае, когда у нас не один продукт, а целое их множество, т.е. продуктовая линейка? Всё становится гораздо интереснее. Конечно, работа внутри компонентных команд продолжается так же, как и в других случаях. Изменяется их взаимодействие друг с другом.
Во-первых, компонентной команде надо учитывать все возможные зависимости их кода от других компонентов. И учитывать, что от продукта к продукту могут меняться интерфейсы и поведение каких-то функций. Отслеживание зависимостей – отдельная большая тема, так что пока не будем трогать её.
Во-вторых, изменяется порядок интеграции каждого компонента в конечные продукты. Теперь каждая базовая конфигурация должна отдаваться на интеграцию только в те продукты, которые требуют функциональность, разрабатываемую в ней. Или же необходимо проверять, чтобы новая функциональность, предназначенная для одного продукта, не начала вдруг работать в другом и вызывать поломки.
В-третьих, разработчик должен постоянно думать о том, как будут работать его изменения на разных продуктах. Ведь в них могут быть задействованы совершенно разные наборы функциональности – поэтому в коде надо делать соответствующие проверки.
Отсюда следуют две возможные линии поведения компонентных команд:
1. Выпуск стольких линеек компонентов, сколько продуктов сейчас находится в работе и сопровождении. Накладный вариант с точки зрения отслеживания изменений и конфигураций, а также сложно с точки зрения интеграции одних и тех же изменений в разные компонентные линейки.
2. Поддержка всех продуктов и их наборов функциональности одновременно в одной линейке компонента. При этом надо организовать код таким образом, чтобы можно было гибко «включать» и «выключать» функциональность через настройки во время «отстройки» системы или во время её инсталляции и запуска в эксплуатацию. Также появляются накладные расходы для разработчиков, которые, ожидая каждого вносимого изменения, вынуждены учитывать, как это изменение повлияет на работу каждой из фич, затронутых измененным кодом.
Отсюда же следует и поведение команды CM. Надо учитывать то, как идет работа в командах и вести стабилизацию компонентов/продуктов и выпуск их базовых конфигураций соответствующим образом. В целом же тема эта обширна и стоит отдельной статьи с большим числом примеров из жизни. Пока что просто примем за данность следующее обстоятельство — продукты и компоненты имеют свойства разветвляться и политики, а проектная документация по CM должна это учитывать.
Вместо заключения
Следующие заметки будут посвящены более практическим вещам — контролю версий и отслеживанию запросов на изменениями.