Анализ функциональных возможностей, предлагаемых на рынке решений, зачастую приводит к выводу, что ни одно из них не удовлетворяет всем требованиям заказчика, и нередко требуется внесение изменений путем конфигурирования или адаптации. Однако не следует забывать про скрытые затраты, которыми чревато применение этих технологий.
Конфигурирование и адаптацию программного обеспечения по смыслу часто путают— оба термина нередко используют как синонимы, когда речь идет о модификации ПО для его соответствия специфическим требованиям заказчика. Программное обеспечение можно назвать конфигурируемым, если его можно настроить через стандартные интерфейсы без программирования дополнительных функций и/или без изменения исходного кода программы. Если требования к системе нельзя удовлетворить без программирования или изменения исходного кода, то программное обеспечение принято называть адаптируемым.
Важным аспектом, отличающим конфигурирование от адаптации, является существенная разница в требуемых ресурсах и уровне компетенции персонала для достижения нужного результата. Адаптация готового решения требует значительно больше ресурсов, причем не только в момент внесения изменений, но и в течение всего жизненного цикла решения.
Конфигурация 1С с нуля за 5 часов. Барбершоп
Возможности системы автоматизации службы поддержки определяются рыночным спросом— если спрос на определенную возможность продукта достаточно высок, производители будут такую возможность разрабатывать для своих решений, и она очень быстро получит распространение на рынке как «стандартная» функция; а если требование не пользуется массовым спросом, то соответствующие функции разрабатываются таким образом, чтобы их можно было поддерживать с помощью дополнительных изменений и настроек, что потребует от пользователя дополнительных расходов. Если же требования к функциональности уникальны, то маловероятно, что пользователь сможет найти уже имеющееся решение, поэтому реализация будет существенно отличаться от возможностей готового (out-of-the-box) продукта. На модификацию в соответствии с требованиями уникальных спецификаций потребуется больше усилий квалифицированных специалистов и неизбежно затраты на реализацию будут выше.
Подходы к настройке и адаптации функциональности ITSM-платформы
Можно выделить шесть основных способов, с помощью которых путем конфигурации и адаптации готовое приложение можно превратить в требуемое решение.
Подбор готовых модулей и компонентов. Этот способ предусматривает выбор одного или нескольких компонентов из набора модульных решений, каждое из которых реализует определенную функциональность так, чтобы сформировать общее решение, «наилучшим образом» отвечающее требованиям клиента.
Настройка пользовательского интерфейса, прав доступа и бизнес-логики. Большинство корпоративных ITSM-решений включают в себя инструментальные средства конфигурации пользовательского интерфейса, права доступа и логики,— это позволяет достигнуть гибкости, необходимой для удовлетворения требований клиента без программирования скриптов, дополнительного кода и глубоких технических знаний. Такой подход предусматривает моделирование последовательности заданий и бизнес-логики, создание и изменение форм пользовательского интерфейса, поддержку прав доступа и «придание» продукту определенного внешнего вида.
Что такое «платформа» программы, «редакция», «конфигурация» и «релиз»
Модификация структуры метаданных. В этом случае структура готовой базы данных меняется таким образом, чтобы она лучше соответствовала требованиям, предъявляемым к данным в конкретной организации: добавление новых таблиц, изменение типов данных, установка атрибутов данных.
Использование встроенной среды разработки. Такая среда занимает промежуточное положение между инструментами настройки и полномасштабной разработкой программного обеспечения. Некоторые решения предоставляют интегрированную среду разработки, в рамках которой пользователь с помощью внутреннего языка программирования может разрабатывать специальные клиентские инструменты.
Разработка с использованием программных интерфейсов. Некоторые из ITSM-решений предоставляют стандартизованные программные интерфейсы (API), применяемые для создания дополнительной функциональности и реализации особенностей работы программного обеспечения за счет прямого обращения к функциональности базовых данных и исходного кода без модификации базовой системы. Это может быть выполнено с помощью привлечения профессиональных разработчиков и является затратным решением как с точки зрения разработки, так и с точки зрения сопровождения готового решения.
Модификация программного кода. Способ предусматривает прямую трансформацию исходного кода для добавления или изменения функциональности системы. Это может быть сделано производителем или пользователем и является самым дорогим и технически сложным методом.
Последствия конфигурирования и адаптации
Любые модификации имеют свои последствия— внесение изменений в готовое решение путем конфигурации и адаптации влияет на затраты, сроки внедрения, функционирование, обслуживание, модернизацию и поддержку продукта. Внедрение системы автоматизации будет отложено на время внесения изменений, причем финансовые потери будут определяться двумя факторами— увеличением затрат, необходимым для модификации продукта, и сдвигом сроков возврата инвестиций (ROI), на фоне того, что лицензии уже приобретены.
Рост операционных расходов и расходов на сопровождение зависит от сложности конфигурации и адаптации. Чем более существенные изменения вносятся в стандартную платформу ITSM, тем больше будут расходы на сопровождение на протяжении всего жизненного цикла продукта. Также нельзя игнорировать возникающую зависимость от качества поддержки адаптированного решения со стороны разработчиков уникального решения.
Адаптация— одна из самых часто упоминаемых причин сбоев в работе программного обеспечения. Технические сбои мешают максимально эффективно использовать решение, которое превращается в расходную часть (пассив), а не в актив. В бизнесе время— деньги, поэтому в результате адаптации программного обеспечения операционные расходы в расчете на звонок в службу поддержки зачастую будут расти, а не снижаться.
С одной стороны, инструментарий службы поддержки необходимо выбирать таким образом, чтобы можно было гарантировать постоянное соответствие этих служб меняющимся бизнес-требованиям. Однако и сами модификации, и их последующие изменения на протяжении всего жизненного цикла продукта также приводят к увеличению затрат. Кроме того, модификации напрямую влияют на поддержку продукта у производителя. У заказчика возникают сложности с поддержкой адаптированных решений, поскольку развитие готового продукта поставщиком не согласовывается с адаптированным решением.
Модернизация адаптивных решений, как правило, требует значительных усилий. Если производитель или внешний разработчик не учитывает необходимость последующих модернизаций, маловероятно, что все изменения инструментария, сделанные в результате конфигурации и адаптации, будут автоматически переноситься на новую версию. И когда эти модификации не сопровождаются необходимой документацией, вполне возможно, что придется проводить аудит всех адаптаций, прежде чем начать вручную переносить модификации в новую версию— а это достаточно длительный и дорогостоящий процесс. Масштаб такого проекта не следует недооценивать, и во многих случаях выгоднее заняться поиском на рынке альтернативных решений.
Когда необходимы изменения готового решения?
С точки зрения бизнеса, следует просто выделить нужную сумму на реализацию конкретной возможности службы поддержки. При этом самый надежный способ гарантировать, что расходы никогда не превысят ценности решения,— это убедиться, что вся функциональность реализована в готовом инструментарии.
Не стоит рассчитывать на то, что готовый продукт будет отвечать всем требованиям, однако необходимо быть уверенным в том, что «небольшое количество жизненно важных» требований, на долю которых придется 80% всей пользы от продукта, можно получить без модификации. Важно четко представлять, какая функциональность имеется в исходном продукте, а что должно быть реализовано за счет конфигурации и адаптации.
В тех случаях, когда это возможно, лучше выбрать инструментарий, в котором оставшиеся обязательные требования можно удовлетворить с помощью инструментов конфигурации, а не за счет адаптации. Это нужно для минимизации количества требований, выходящих за рамки готовой функциональности— известно, что формулировка «нам это нужно» на самом деле означает «было бы неплохо это иметь». Не каждое требование можно рассматривать как обязательное, поэтому необходимо, чтобы в компании была принята политика, в соответствии с которой все требования, предполагающие затратную адаптацию продукта, подтверждались с точки зрения их необходимости для бизнеса. Такая политика позволит минимизировать общую стоимость владения в течение жизненного цикла продукта. Важно задать себе два вопроса: насколько действительно нужна эта возможность и есть ли риск, что стоимость реализации этой функциональности превысит эффект от ее применения?
Каждое требование, которое может быть выполнено за счет использования функций готового продукта, «оплачивается» из суммы, потраченной на покупку лицензии, и существенно экономит общие затраты. Предположим, что инструментарий службы поддержки должен соответствовать 100 требованиям, 80 из которых выполняются в готовом решении, а 20 необходимо реализовать дополнительно. Пусть лицензионные затраты составляют 2000 долл. на пользователя в год, в таком случае стандартное требование в расчете на пользователя будет стоить 25 долл.
Предположим, что средние затраты на изменения составят: а) на реализацию одного требования с помощью конфигурации— 50 долл, что равняется примерно 2-4 часам работы администратора системы; б) на реализацию одного требования с помощью адаптации— 1 тыс. долл., что составляет примерно 1-2 дня работы разработчика системы. В таком случае, если 20 требований можно на 50% выполнить с помощью конфигурации, а на 50% с помощью адаптации, то вы можете добавить к общей сумме 500 долл. за изменения путем конфигурации и 10 тыс. долл. за изменения путем адаптации. Если у продукта 20 пользователей, и в течение первого года нет необходимости в дальнейших изменениях, то затраты за первый год (исключая расходы на услуги реализации) составят 50500 долл. против 40 тыс. Это на 25% больше, чем если бы готовое решение изначально соответствовало всем требованиям. Кроме того, при отсутствии должного управления, по мере увеличения срока использования продукта те изменения, которые внесены в результате его адаптации, могут вызвать экспоненциальный рост расходов.
Для каждого конкретного набора инструментальных средств необходимо выяснить, каким функциональным требованиям удовлетворяет готовое решение, а какие можно выполнить за счет конфигурации или адаптации. Стоит с осторожностью стремиться к тому, чтобы про созданное решение можно было сказать, что «наш продукт может делать все». Гибкость никогда не дается бесплатно.
Также важно помнить, что серьезная адаптация решения может иметь далеко идущие последствия— это повлияет на отдачу от инвестиций на всех этапах жизненного цикла продукта, от реализации и использования до поддержки и модернизации. Необходимо расставить приоритеты требований с учетом их цены и пользы для бизнеса, а не в зависимости от того, кто выдвигает эти требования и насколько настойчиво. Как правило, 80% ценности инструментария службы поддержки приходится на 20% его функциональности. Стоит ли тратить 250% от стоимости готового решения на то, чтобы добиться выполнения оставшихся 20%?
Как избежать столь высоких затрат на модификацию стандартных решений, предлагаемых на рынке? Выход— использование продуктов «out-of-the-box», концепция разработки которых изначально опирается на стандарты, такие как ITIL.
ITIL как средство стандартизации
Решения, построенные по принципам ITIL, обладают следующими возможностями:
Изначальная интеграция всех основных процессов ITIL: управление инцидентами, изменениями, задачами, конфигурациями и сервисами. Процессы могут реализовываться поэтапно или развертываться в рамках полной инсталляции пакета, что избавляет от необходимости покупать дополнительно отдельные ITSM-модули.
Возможность встраивания сформулированных заказчиком бизнес-правил или специфических процессов в момент внедрения продукта, а также возможность их изменения без дополнительного кодирования.
Использование методологии ITIL в качестве основы позволяет продукту иметь функциональность, которая руководит пользователем во всех процессах, опираясь на наилучшие практические решения ITIL, но при этом дает возможность изменить эти «изначальные» процессы таким образом, чтобы удовлетворить специфические бизнес-требования организации.
Подобный комплексный подход к развитию и техническому сопровождению позволяют свести к минимуму затраты на конфигурацию и/или адаптацию готового решения. Желательно также, чтобы компания, принявшая решение о внедрении новых или совершенствованию уже существующих ИТ-процессов, получала доступ к лучшим практическим решениям по автоматизации управления и сопровождению ИТ в своей отрасли. Такой подход позволит избежать типовых ошибок и сэкономить время на решении известных проблем.
Одним из примеров реализации концепции «out-of-the-box» является предлагаемый компанией Axios Systems продукт assyst (см. рисунок), основанный на ITIL v3. Заказчику не нужно быть специалистом по ITIL, чтобы воспользоваться преимуществами процессного подхода и функциональностью assyst— это продукт, готовый к внедрению в организации и позволяющий свести к минимуму необходимость конфигурации и адаптации. Решение assyst изначально создавалось таким образом, чтобы его можно было использовать при постоянно изменяющихся бизнес-требованиях.
Рисунок. Интеграционная архитектура assyst
Специфические детали описания бизнес-среды каждой компании хранятся в центральной базе данных, что гарантирует согласованность и актуальность информации. Такая база разделена на блоки данных (Customer Service Groups), предназначенные для конкретных рабочих групп, что позволяет одной системе обслуживать единые ИТ процессы в различных подразделениях, или обслуживать отличающиеся ИТ подразделения разных компаний. Это дает преимущества для провайдеров сервисных услуг и позволяет предоставлять услуги аутсорсинга различных процессов для нескольких заказчиков одновременно. В решении изначально интегрированы процессы ITIL используются известные, опробованные заранее процедуры, шаблоны, формы и подпроцессы, что существенно снижает затраты на доработку системы.
Портал самообслуживания assystNET дает возможность конечным пользователям регистрироваться в системе через Web, сообщать о своих инцидентах и отслеживать процесс их решения. Благодаря этому экономятся ресурсы первой линии службы поддержки и увеличивается эффективность работы. Ключевой особенностью решения «out-of-the-box» является возможность настройки внешнего вида портала с помощью встроенных средств конфигурации без кодирования, возможность использования отдельного Web-интерфейса под каждого заказчика.
Возможности assyst по интеграции и обмену данными обеспечиваются благодаря специализированным модулям, адаптерам, коллекторам, шлюзам, позволяющим интегрировать решение IT Service Management assyst с любым внешним приложением или источником данных (см. рис.). Интеграционная платформа позволяет организовать любой способ обмена данными: одно- и двунаправленный, событийный, по расписанию, от самых простых вариантов запуска внешних приложений до глубокой интеграции приложений с помощью встроенного API. Assyst позволяет обмениваться релевантной информацией с другими ITSM-системами, внешними системами мониторинга и сбора информации об ИТ-инфраструктуре.
Особенности assyst
Успех применения систем типа Axios assyst определяется особенностями их адаптации и конфигурирования для нужд конкретного заказчика— без учета тонкостей российского ИТ-рынка вообще и сектора решений для организации и автоматизации служб технической поддержки, в частности, инвестиции в решения управления ИТ будут неэффективны.
Конфигурирование и адаптация программного обеспечения предполагают наличие у заказчика некоторого готового программного решения (системы), в той или иной степени отвечающего его требованиям по различным критериям: стоимость лицензий, стоимость внедрения, функционал, стоимость последующего сопровождения и т.п. Несмотря на то, что сегодня преобладает тенденция использования готовых решений, стоит помнить и о том, что у заказчика всегда есть выбор— использовать уже имеющееся решение (путем его конфигурации или адаптации) либо создать собственное, заказав его разработку своему ИТ-подразделению или обратившись к внешнему разработчику.
В секторе решений для организации служб технической поддержки, конечно, повсеместно используются готовые системные решения различной степени сложности и функциональности. Необходимо отметить, что данные решения состоят не только из выбора системы автоматизации для реализации требований заказчика и последующего ее внедрения, а еще включают в себя предварительное обследование, анализ, построение организационно-процессной части решения и формализацию требований к системе автоматизации. Безусловно, стандартом «де-факто» по построению ИТ-процессов и организации служб технической поддержки ИТ является сегодня библиотека ITIL, однако в ней нет четких требований и вариантов построения процессов. Предполагается, что заказчик самостоятельно или при помощи внешних консультантов выстроит процессы в соответствии со своими требованиями, рекомендациями ITIL, внутренней культурой и экспертизой организации. В этом случае вопрос выбора системы автоматизации остается важной и ответственной частью решения, который априори будет решаться с учетом действительно важных, отфильтрованных и ранжированных по приоритетам требований заказчика, дав ему возможность более свободно ориентироваться в различных системах, а также в вопросах сравнения подходов к внедрению систем (конфигурация или адаптация).
Продукт аssyst представляет собой сбалансированное решение, позволяющее при необходимости достаточно быстро автоматизировать процессы ITIL в службе технической поддержки ИТ за счет богатого функционала. В системе заложена большая вариативность и конфигурируемость автоматизируемых процессов, причем основная часть потенциальных вариантов конфигурации процессов взята из рекомендаций ITIL, и это снижает риски, возникающие при постановке задач и формализации требований к системе.
Источник: www.osp.ru
Software Configuration Management // Конфигурации и baselines
Итак, по горячим следам продолжаю публиковать материалы, касающиеся основ управления конфигурацией программных средств. Прочитайте предыдущую заметку, если вдруг пропустили.
Ниже речь пойдет о следующих вещах:
— Рабочие продукты и конфигурации;
— Компонентная разработка;
— Продуктовые линейки;
— Стабилизация результатов работы;
— Baselines AKA базовые конфигурации;
— Конфигурации при компонентной разработке;
— Конфигурации при наличии продуктовых линеек.
Рабочие продукты и конфигурации
Что же будет являться рабочими продуктами в рамках проекта? Понятно, что для маркетинга и менеджмента продукт будет ровно один – тот, за который компания получит деньги. Ну, или несколько, по числу видов коробок, выдаваемых на рынок. Нас же интересует «нижний уровень» – то, чем будут оперировать постановщики задач, разработчики, тестеры и вообще каждый участник проекта.
Задача CM – определить множество тех элементов, которые будут создаваться и изменяться командой. На этом этапе появляется понятие «configuration item» («элемент конфигурации») – это атомарный элемент, которым наиболее удобно управлять в рамках разработки. В дальнейшем будем называть его просто «CI».
- рабочие документы;
- файлы исходных кодов;
- файлы ресурсов;
- файлы, создаваемые в результате сборки (исполняемые файлы, dll’ки);
- инструменты, используемые для разработки (их мы тоже должны учитывать для стандартизации и упрощения взаимодействия в команде);
К объектам, попадающим под действие 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 должна это учитывать.
Вместо заключения
- идентификация рабочих продуктов;
- стабилизация результатов работы и определение базы для дальнейшей работы;
- Baseline (configuration management). en.wikipedia.org/wiki/Baseline_%28configuration_management%29
Следующие заметки будут посвящены более практическим вещам — контролю версий и отслеживанию запросов на изменениями.
Источник: habr.com
Понятие конфигурации
Конфигурация (configuration) — это текущее актуальное состояние холархии системы и её описаний. Обычно в ходе разных проектов порождается множество самых разных вариантов частей воплощения системы, множество самых разных описаний системы, относящихся к разным моментам времени, разработанных самыми разными людьми, и нужно понимать — какие изо всех этих частей системы входят в холархию, и какие описания являются для них актуальными.
В ходе разработки инженерной системы обычно рассматривают самые разные варианты требований, архитектуры, неархитектурной части проекта/design. И эти описания ещё и изменяются каждое по нескольку раз. Как определить, какие из этих описаний должны быть использованы изготовителями системы?
А если часть изготовителей изменили систему так, что она уже не соответствует этим описаниям, а часть изготовителей работает «как договаривались» — можно ли быть уверенным, что из изготовленных частей можно будет собрать работающую систему? Конечно, нет. Ошибки, связанные с тем, что некоторые части системы и их описания не известны, или даже известны, но не соответствуют друг другу, весьма распространены.
Конфигурация системы — это сами части системы и их описания. Сама конфигурация может быть определена (defined) и, соответственно, описана (described). Описание конфигурации (configuration description, иногда говорят и «конфигурационное описание») в речи часто сокращают до просто «конфигурация» — и разницу между конфигурацией (составом самой системы) и описанием конфигурации нужно определять из контекста так же, как разницу между архитектурой и архитектурным описанием, когда для обоих используют слово «архитектура».
Управление конфигурацией (configuration management) — отслеживание, что конфигурация воплощения системы и описания системы известны и соответствуют друг другу. Это дисциплина лежит посредине между менеджерскими и инженерными дисциплинами. Конфигурация составляется изконфигурационных единиц (configuration item) — самых мелких частей, на которые делится система в части её логистики. Речь идёт о единицах передачи частей системы и описаний этих частей от одного исполнителя работ к другому, от одной обработки к другой.
Инженеры часто имеют более детальные описания частей системы, чем это требуется для организации перемещения рабочих продуктов. Например, каждый из многих миллиардов транзисторов на чипе уникален, но конфигурационной единицей в цеху электроники служит сам чип но не эти транзисторы, ибо отдельно транзисторы никому не передаются.
Чтобы не потерять эти конфигурационные единицы при учёте, иметь возможность на них сослаться в разговоре и различных описаниях системы, им даются индивидуальные обозначения (designations). Стандарт IEC 81346 представляет собой стандарт, в котором предлагается типовой способ такого описания, учитывающий системный подход — наличие нескольких альтернативных структур системы (компонентной/функциональной, модульной/продуктной, размещений, и т.д.).
Описания системы всегда являются описаниями каких-то конфигурационных единиц и их обозначения обычно создаются путём приписывания к названию конфигурационной единицы вида описания. Если для каких-то целей вдруг потребовалось описать три или четыре конфигурационных единицы, то скорее всего речь идёт об описании какой-то системы из этих единиц и нужно просто создать из них новую конфигурационную единицу, которой и будет соответствовать описание.
Версия (version) системы — это её конфигурация по состоянию на какой-то момент времени. Отслеживание смены версий в результате изменений (changes) нужно для того, чтобы точно указывать, какая из многочисленных возникающих и исчезающих по ходу проекта конфигураций системы имеется ввиду.
Базис (baseline, конфигурационный базис) — это проверенная на целостность и утверждённая административно версия.
Управление изменениями (change management) часто включают в состав управления конфигурацией (так и пишут: «управление конфигурацией и изменениями», но обычно это отдельная дисциплина. Её не нужно путать с управлением организационными изменениями — как нужно менять организацию, чтобы это не вызывало сопротивления людей и вело к положительным результатам. Инженерное управление изменениями — это про то, как принимать решения по изменению конфигурации, чтобы минимизировать конфигурационные ошибки. Для этого в конфигурации различают обычные рабочие версии с более простыми внесениями изменений и базисы, внесение изменений в которые связано с дополнительными инженерными и административными проверками на целостность конфигурации.
Источник: studfile.net