Управление конфигурациями – процесс, отвечающий за управление информацией о конфигурационных единицах (включая их взаимоотношения), необходимой для предоставления ИТ-услуг.
Цель процесса управления конфигурациями - сбор и актуализация информации о составляющих частях IT-инфраструктуры, обеспечение данной информацией прочих процессов Управления услугами.
Конфигурационная единица (сonfiguration item или CI ) – элемент инфраструктуры или объект, связанный с элементами инфраструктуры (например, RFC), который находится/ должен находиться под контролем процесса управления конфигурациями. Конфигурационными единицами могут являться любые элементы, которыми необходимо управлять с точки зрения жизненного цикла ИТ-услуги. Точных рекомендаций по тому, что считать конфигурационной единицей, не существует. Однако различные источники (в том числе ITIL ) дают подсказки: это может быть аппаратное и программное обеспечение, документация и даже персонал. То есть любой ИТ-актив, сервисный компонент или любой другой элемент, который задействован на протяжении жизненного цикла ИТ-услуги.
Конфигурационная база данных (Configuration Management Database или CMDB ) – база данных, содержащая все необходимые сведения по всем CI и о связях между ними. Все Конфигурационные Единицы должны быть включены в Конфигурационную Базу Данных (CMDB), которая отслеживает все ИТ-компоненты и взаимоотношения между ними. В самой примитивной форме Конфигурационная База Данных представляет собой набор бумажных форм или электронных таблиц.
Базисная конфигурация (сonfiguration baseline или CB ) – конфигурация продукта/ системы в определенный момент времени, отражающая структуру и детали этого продукта/ системы. Базисная конфигурация позволяет восстановить состояние продукта/ системы. По сути это актуальное состояние Конфигурационной Единицы.
Управление активами – бухгалтерский процесс мониторинга активов, цена приобретения которых превышает установленный предел. Учитываются не только ИТ-объекты, но связи между объектами не отслеживаются.
Управление конфигурациями (Configuration Management) – процесс хранения технической информации о CI и связях между ними. Это процесс, который отвечает за необходимые конфигурационные элементы для оказания ИТ услуги и за их связи с управлением. Этой информацией управляют через конфигурационные элементы на протяжении всего жизненного цикла.
Управление конфигурациями не следует путать с Управлением активами .
- Управление активами – это бухгалтерский процесс мониторинга амортизации активов, чья закупочная цена превышает определенную величину. Мониторинг ведется путем учета закупочных цен, амортизации, месторасположения активов. Эффективно работающая система Управления активами может послужить основой для системы Управления Конфигурациями.
- Управление конфигурациями идет дальше, учитывая также информацию о взаимоотношениях между Конфигурационными Единицами и решая задачу стандартизации и авторизации единиц CI. Управление Конфигурациями также контролирует информацию о статусе ИТ-компонентов, их расположении, произведенных в них изменения и т. д.
Основные действия по управлению конфигурациями это:
- Сбор информации о каждом конфигурационном элементе
- Определение и анализ связей и взаимодействий между разными конфигурационными элементами
- Накопление информации в специальные базы данных управления конфигурациями (CMDB Configuration Management Database), где хранятся записи о конфигурациях на протяжении всего их жизненного цикла.
- Контроль целостности системы после каждого изменения конфигураций
- Постоянное слежение за ИТ инфраструктурой и ее анализ
Процесс конфигурационного управления дает логичную модель ИТ инфраструктуры и услуг. Он определяет, следит, обеспечивает и контролирует развитие различных конфигурационных элементов в инфраструктуре.
Когда речь идет об ИТ-инфраструктуре (оборудование и программное обеспечение, документация и вспомогательные службы, окружающая среда и подготовленный персонал), обычно возникают следующие задачи:
- разработка правил учета элементов ИТ-инфраструктуры;
- осуществление учета в соответствии с разработанными правилами;
- разработка правил получения/предоставления информации и проверки точности;
- осуществление повседневной деятельности в соответствии с разработанными правилами.
При разработке правил учета особое внимание следует уделить разработке системы классификации конфигурационных элементов.
CMDB должна содержать и предоставлять подробные данные о конфигурационных единицах, предоставляемых и используемых услугах, о потребителях и конечных пользователях различных служб, ИТ-персонале, поставщиках, субподрядных организациях и т.д., а также о взаимосвязях между всеми перечисленными элементами.
Так-же база в идеале должна содержать информацию об известных ошибках, структуре и размещении бизнес-подразделений. CMDB позволяет выдавать ответы на самые различные запросы, в том числе, быстро предоставляя следующую информацию:
- состав релиза приложения, включая все необходимые конфигурационные единицы и их версии;
- составные конфигурационные единицы, их компоненты, номера версий, тестовое и эксплуатационное окружения;
- конфигурационные единицы, на которые может оказать влияние некоторый запрос на внесение изменения;
- все запросы на внесение изменений в конкретную конфигурационную единицу;
- конфигурационные единицы, закупленные у некоторого поставщика за определенный период;
- оборудование и программы, находящиеся в некотором определенном месте, например, с целью обслуживания и проверки;
- конфигурационные единицы, подлежащие обслуживанию, обновлению или замене;
- связанные с конфигурационной единицей зарегистрированные проблемы и инциденты;
- все конфигурационные единицы, имеющие отношение к проблеме.
Существует несколько различных подходов к построению CMDB :
- использование существующей в организации бухгалтерской системы;
- создание собственной базы данных;
- использование специализированного средства автоматизации.
Создание собственной системы - наиболее гибкий и полный вариант. Основным его недостатками является высокая ресурсоемкость.
Адаптация бухгалтерских систем для нужд управления конфигурациями часто оказывается малореальной в связи с отсутствием возможности удобного предоставления доступа к информации большому числу сотрудников ИТ-службы и невозможностью качественного отображения взаимосвязей между различными конфигурационными единицами. Доработка таких систем своими силами достаточно ресурсоемкий процесс, как и привлечение к доработке разработчиков этой системы.
Специализированные системы лишены этих недостатков, поскольку требуют лишь незначительной настройки и могут быть внедрены в сжатые сроки. С другой стороны, за это приходится платить некоторой потерей гибкости и снижением возможностей глубокой настройки, а иногда и процессы должны строиться так, как того требует продукт. Системы различаются качеством реализации процессов, полнотой соответствия рекомендациям ITIL , качеством и полнотой отображения информации, удобством ее визуализации и, что немаловажно для систем этого класса в нашей стране, полнотой и качеством локализации.
Часто внедрение подходов библиотеки ITIL приносит успех, если начинать внедрение с Управления конфигурациями и Управления изменениями (Configuration & Change Management). Такая связка логична, потому что эти процессы наиболее взаимозависимы и при этом сильно влияют на другие процессы. С одной стороны информация об актуальной конфигурации ИТ-сервисов, хранящаяся в CMDB , является необходимым условием для Управления инцидентами и других процессов, как оперативных (Управление проблемами, изменениями, релизами ), так и тактических (Управление уровнем сервиса, финансами, мощностью, доступностью, непрерывностью ). С другой – без эффективного Управления изменениями невозможно достичь главной цели Управления конфигурациями – актуальности данных в CMDB .
Правильная реализация процессов управления конфигурацией позволяет не только решать проблемы путем идентификации причины «поломки» (какой элемент вышел из строя, и как его «починить»), но и полностью предотвращать их возникновение за счет оценки логики работы с данными. Грамотная оценка производимых изменений позволяет поддерживать системы в работоспособном состоянии, а неправильная - приводит к пустой трате денежных средств.
Помимо финансовых затрат, неверное управление конфигурацией ведет к расходованию иных ресурсов, например человеко-часов. Ресурсы приходится затрачивать и на работу с клиентами во время устранения неполадок с IT-инфраструктурой. Сложно управлять изменениями, если внедрение решений не подкрепляется CMS-системой. Поэтому сегодня мы расскажем, о внедрении процессов управления конфигурацией и на какие аспекты следует обратить пристальное внимание.
С чего начать
Прежде чем начинать внедрение, необходимо объяснить смысл CMS-системы всем участникам экосистемы: членам команды, клиентам и др. Это важно, поскольку в дальнейшем каждая сторона будет принимать участие в управлении конфигурацией - члены команды CMS должны предоставлять точную информацию своим коллегам, ответственным за инциденты и изменения, а действия, производимые IT-специалистами должны отображаться в базе данных управления конфигурацией (CMDB).Для организации CM хорошо походит известная модель непрерывного улучшения процессов PDCA. Следуя этой модели, внедрение CMS можно разделить на четыре части: планирование и определение, контроль, учет состояния, аудит.
Поскольку управление конфигурацией станет основой для предоставления услуг и бизнес-процессов компании, то для его качественного внедрения нужно составить план.
Составление плана
Мы рекомендуем начать планирование управления конфигурацией с наиболее критичных бизнес-процессов - обработки инцидентов и проблем. Служба технической поддержки всегда загружена заявками от пользователей, поэтому важно обеспечить их своевременное исполнение. Реализация проекта с этого класса услуг позволит оптимизировать работу технической поддержки, что непременно скажется на эффективности других отделов компании.При планировании также стоит уделить внимание критическим службам и сервисам, которые необходимы для управления, чтобы заложить плацдарм для будущего масштабирования (что зависит от темпов роста компании и набора предоставляемых услуг).
Определение исходного состояния
Этап определения исходного состояния - это следующий шаг после планирования, который нужен, чтобы понять из каких элементов состоит инфраструктура компании в настоящий момент. Такой снимок в будущем может быть использован для сравнения состояний, например, «в этом году объем имущества увеличился на 20%, что привело к появлению 2 тыс. новых изменений».Как только исходное состояние определено, следует убедиться, что ему соответствуют соглашения об уровне услуг (SLAs), операционные соглашения (OLAs), внешние договоры (UCs), связанные с IT-инфраструктурой и сервисами организации.
Определение исходного состояния стоит начинать с какого-либо одного сервиса, расписав все его компоненты. При этом полученная информация должна заноситься в базу данных ITSM-платформы, например ServiceNow, или простую базу данных CMDB - это может быть таблица в Excel или Access.
Что касается платформы ServiceNow, то она предоставляет удобные инструменты для создания и ведения системы управления конфигурацией. Пользователю доступны двести типов конфигурационных единиц, таких как компьютеры, ноутбуки, серверы, оргтехника, программное обеспечение, интернет-ресурсы и др. Импортом в базу данных CMDB занимается приложение ServiceNow Discovery, которое автоматически сканирует сеть и добавляет найденные единицы.
Также отметим, что важно определить ответственное лицо за внесение информации в базы данных.
Контроль
Следующим этапом внедрения управления конфигурацией является контроль изменений - процесс, который должен применяться ко всем действиям, производимым с объектами ИТ-инфраструктуры. Для успешного осуществления контроля нужно соблюдать ряд основных требований:- Тесно сотрудничать с работниками, осуществляющими контроль изменений, дабы работа управления конфигурациями следовала корпоративным политикам об изменениях. Без контроля изменений CMS/CMDB быстро устареет.
- Конфигурационные единицы, участвующие в процессе оказания услуги, должны быть с ней связаны. Это даст пользователю возможность быстро выбрать требуемый сервис. В этом случае все CI добавятся автоматически.
- ИТ-специалисты, отвечающие за систему управления конфигурацией, должны участвовать в консультативных советах по изменениям (CAB), чтобы отображать в CMS и CMDB производимые с инфраструктурой изменения. При этом все вносимые изменения должны проверяться, перед закрытием тикета как успешного.
Учет состояния
Следующий этап - учет состояния, который нужен для отслеживания жизненного цикла всех конфигурационных единиц (CI) - «строительных блоков», включающих в себя серверы, маршрутизаторы, программное обеспечение и все системы, на которых оно построено - и их текущего состояния. Статусы жизненного цикла CI должны быть определены в политике CMS, чтобы гарантировать согласованность и документальное подтверждение всех стадий, через которые проходит конфигурационная единица. Среди таких этапов выделяют: запланировано, приоритет повышен, доставлено, тестовая среда, рабочая среда, не используется, удалена.Аудит
Заключительный этап внедрения CMS называется проверка и аудит. Его задача - гарантировать достоверность данных, представленных в CMDB: все рабочие CI должны соответствовать тому, что указано в CMS/CMDB, а документация поддержки должна точно описывать все CI. Чтобы удовлетворить эти требования, важно составить и утвердить план проверок, содержащий ответы на следующие вопросы:- Имеются ли специальные инструменты для проведения проверок?
- Требуется ли физическая проверка?
- Каковы нормативные требования?
- Есть ли сертификация по стандарту ISO 20000 и должны ли выполняться IL3, BASEL 3 или NGN224, требующие вмешательства третьей стороны?
При этом, различные ITSM-системы (включая ServiceNow) позволяют проводить аудит в автоматическом режиме, используя для этого специальные дашборды, переводящие огромное количество информации в вид, понятный пользователю.
В заключение хотелось бы отметить, что управление конфигурацией - это лишь один из аспектов эффективного использования ИТ-инфраструктуры и качественного предоставления услуг. Если к нему добавить такие процессы, как управление активами и управление мощностями, то вы получите комплексную модель гибкого и рационального использования всех имеющихся в вашем распоряжении ресурсов. О них мы планируем поговорить в наших следующих материалах.
P.S. Другие материалы из нашего блога «ИТ Гильдия».
В программных проектах необходима специальная деятельностьпо поддержанию файловых активов проекта в порядке, которая называется конфигурационным управлением .
Выделим две основные задачи в конфигурационном управлении:
- управление версиями отвечает за управление версиями файлов и выполняется в проекте на основе специальных программных пакетов – средств версионного контроля ;
- управление сборками - это автоматизированный процесс трансформации исходных текстов ПО в пакет исполняемых модулей, учитывающий многочисленные настройки проекта, настройки компиляции, и интегрируемый с процессом автоматического тестирования.
Эта процедура является мощным средством интеграции проекта, основой итеративной разработки.
Единицы конфигурационного управления:
Конфигурационное управление имеет дело с меняющимися в процессе продуктами, состоящими из наборов файлов. Такие продукты принято называть единицами конфигурационного управления (configurationmanagementitems). Вот примеры:
Пользовательская документация;
Проектная документация;
Исходные тексты ПО;
Пакеты тестов;
Инсталляционные пакеты ПО;
Тестовые отчеты.
У каждой единицы конфигурационного управления должно быть следующее :
Структура – набор файлов.
Ответственное лицо и, возможно, группу тех, кто их разрабатывает, а также более широкую и менее ответственную группу тех, кто пользуется этой информацией.
Практика конфигурационного управления – кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления в средство управления версиями, правила именования и комментирования элемента в этой версии, дальнейшие манипуляции с ним там и пр. Более высокоуровневые правила, связанные, например, с правилами изменения тестов и тестовых пакетов при изменении кода.
Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ. Есть не у всех элементов, например, может не быть у документации, тестовых пакетов.
Элементы конфигурационного управления могут образовывать иерархию.
Управление версиями:
Поскольку программисты имеют дело с огромным количеством файлов, многие файлы в один момент могут быть необходимы нескольким людям и важно, чтобы все они постоянно составляли единую, как минимум, компилирующуюся версию продукта, необходимо, чтобы была налажена работа с файлами с исходным кодом. Также может быть налажена работа и с другими типами файлов. В этой ситуации файлы оказываются самыми младшими (по иерархии включения) элементами конфигурационного управления.
Одновременно может существовать несколько версий системы – и в смысле для разных заказчиков и пр., и в смысле одного проекта, одного заказчика, но как разный набор исходных текстов. И в том и в другом случае в средстве управления версиями образуются разные ветки .
Каждая ветка содержит полный образ исходного кода и других артефактов, находящихся в системе контроля версий. Каждая ветвь может развиваться независимо, а может в определенных точках интегрироваться с другими ветвями. В процессе интеграции изменения, произведенные в одной из ветвей, полуавтоматически переносятся в другую.
Управление сборками:
Итак, почему же процедура компиляции и создания exedll файлов по исходникам проекта – такая важная процедура? Потому что она многократно в день выполняется каждым разработчиком на его собственном компьютере, с его собственной версией проекта. При этом отличается:
Набор подпроектов, собираемых разработчиком; он может собирать не весь проект, а только какую-то его часть; другая часть либо им не используется вовсе, либо не пересобирается очень давно, а по факту она давно изменилась;
Отличаются параметры компиляции.
При этом если не собирать регулярно итоговую версию проекта, то общая интеграция может выявить много разных проблем:
Несоответствие друг другу различных частей проекта;
Наличие специфических ошибок, возникших из-за того, что отдельные проекты разрабатывались без учета параметров.
В связи с этим процедуру сборки проекта часто автоматизируют, то есть выполняют не из среды разработки, а из специального скирпта – build-скрипта. Этот скрипт используется тогда, когда разработчику требуется полная сборка всего проекта. А также он используется в процедуре непрерывной интеграции (continuesintegration) – то есть регулярной сборке всего проекта (как правило – каждую ночь).
Процедура непрерывной интеграции включает в себя и регрессионное тестирование, и часто – создание инсталляционных пакетов . Общая схема автоматизированной сборки представлена следующим образом:
Тестировщики должны тестировать по возможности итоговую и целостную версию продукта, так что результаты регулярной сборки оказываются очень востребованы. Кроме того, наличие базовой, актуальной, целостной версии продукта позволяет организовать разработку в итеративно-инкрементальном стиле, то есть на основе внесения изменений. Такой стиль разработки называется baseline-метод.
Понятие baseline
Baseline – это базовая, последняя целостная версия некоторого продукта разработки, например, документации, программного кода и т.д.
Подразумевается, что разработка идет не сплошным потоком, а с фиксацией промежуточных результатов в виде текущей официальной версии разрабатываемого актива. Принятие такой версии сопровождается дополнительными действиями по оформлению, сглаживанию, тестированию, включению только законченных фрагментов и т.д. Этот результат можно посмотреть, отдать тестировщикам, передать заказчику и т.д. Baseline служит хорошим средством синхронизации групповой работы.
Baseline может быть совсем простой – веткой в средстве управления версиями, где разработчики хранят текущую версию своих исходных кодов. Единственным требованием в этом случае может быть лишь общаякомпилируемость проекта.
Baseline может также поддерживаться непрерывной интеграцией.
Важно, что Baseline не должна устанавливаться слишком рано. Сначала нужно написать какое-то количество кода, чтобы было что интегрировать. Кроме того, вначале много внимания уделяется разработке основных архитектурных решений, и целостная версия оказывается не востребованной. Но начиная с какого-то момента она просто необходима. Какой этот момент – решать членам команды. Наконец, существуют проекты, где автоматическая сборка не нужна вовсе – это простые проекты, разрабатываемые небольшим количеством участников, где нет большого количество исходных текстов программ, проектов, сложных параметров компиляции.
Конфигурация - это знание о том, какова работающая (актуальная) система, выделенная из множества ее возможных вариантов. Конфигурация находится под контролем, если конфигурация определения системы соответствует конфигурации воплощения системы . Если какие-то части этих конфигураций не соответствуют друг другу, то говорят о конфигурационных коллизиях .
Управление конфигурацией (configuration management) - техническая дисциплина системной инженерии, обеспечивающая поддержание надлежащей (задуманной, одобренной) конфигурации системы во время всего её жизненного цикла. Если говорить попроще, то управление конфигурацией - это практика, обеспечивающая на протяжении всего жизненного цикла совместимость версий (отсутствие коллизий!) и полноту частей системы (отсутствие коллизий!).
Управление конфигурацией - практика системноинженерного менеджмента - она занимается поддержанием целостности системы на протяжении всего ЖЦ. В рамках этой практики выпускаются различные виды спецификаций закупаемого/изготавливаемого оборудования/изделий - BOM (bill of materials, список комплектующих).
Отнесение управления конфигурацией к системной инженерии означает, что конфигурация обязательно относится ко всей системе.
Управляющий конфигурацией - системный инженер, наряду с инженером по требованиям, системным архитектором, интегратором.
Основные понятия
Управление конфигурацией включает в себя следующие понятия:
- базис (configuration baseline) - исходная (утвержденная) конфигурация. Базис определяется на следующих этапах:
| Базис | Определяется на этапе | Тип спецификации | Характеристики | Описываемый элемент |
|---|---|---|---|---|
| Функциональный | Выбор концепции | A | Функциональные спецификации | Система |
| Физический (Allocated) | Техническое проектирование | B | Проектная документация | Элемент конфигурации |
| Продукции (Product) | Техническое проектирование | C, D, E | Производственно-технологическая документация | Элемент конфигурации |
- версия/ревизия (version/revision);
- элемент конфигурации
(configuration item, CI) - элемент системы, который является основой для описания и формального управления проектированием системы, базовая часть системы, которая проектируется, конструируется и создается силами одной организации. Характеристики и интерфейсы CI с другими составными частями должны быть определены и контролироваться, чтобы гарантировать надлежащее функционирование CI в составе системы в целом. Различают:
- аппаратные элементы конфигурации (hardware CI - HWCI)
- элементы конфигурации программного обеспечения компьютера (computer software CI - CSCI)
Практики
Управление конфигурацией, в том числе и управление изменениями невозможно рассматривать отдельно от управления данными (управления информацией, интеграции данных жизненного цикла и т.д.). Сюда попадают следующие практики:
- практика выпуска (release) инженерных артефактов (например, выпуск чертежей) - можно обсуждать, является ли hand-over данных входящим в эту практику, или должен рассматриваться отдельно
- практика выпуска заказных спецификаций (BOM, bill of materials)
- практика запросов на изменения
- практика изменения проекта
- практика управления данными (чтобы нужные заинтересованным сторонам данные оказывались у них в нужное время. Да, "управление требованиями", как часть инженерии требований, отвечающая именно за то, чтобы требования адекватно хранились и адекватно предоставлялись по запросам заинтересованных сторон - это часть именно этой практики. Ибо нет никаких особенностей именно у "управления требованиями" в отличии их от управления любыми другими данными).
Дисциплина управления конфигурацией имеет следующие основные основные практики:
- Идентификация - поддержка инженерных разбиений (классификаций, кодировок) и именования/кодировки отдельных конфигурационных единиц (configuration items).
- Конфигурационный учет/регистрация
- административное обеспечение взаимного соответствия:
- проекта (включая требования),
- исполнительной документации (as built, "что мы думаем о реальной системе"),
- самой системы "в железе и бетоне".
- Контроль версий (version/revision control): обеспечение того, что базис (утвержденная для каких-то целей конфигурация) собирается из взаимно соответствующих версий частей системы (будь то версии проектной или исполнительной документации, или же версии самой системы "в железе и бетоне"). Софтверщикам с их CVS и SVN против git и Mercurial должно быть понятно, о чем это.
Основные принципы
Управление конфигурацией очень просто, когда есть один административный центр, который вводит
- обязательную идентификацию
- обязательный регламент учёта
- централизованное версионирование
При распределенной разработке (collaborative engineering , concurrent engineering) каждая из участвующих в проекте организаций имеет собственные предпочтения по управлению конфигурацией (кодировки, учётные регламенты, версионирование). Собрать из этого распределенного конфигурационного месива базис обычно представляет собой непростую задачу.
Так, любая PLM-система поддерживает управление конфигурацией. Но если в расширенной организации (extended enterprise) используется несколько разных PLM-систем, то немедленно начнутся проблемы. Еще бОльшие проблемы будут, если нет полноценной (организация+софт) системы управления жизненным циклом (СУЖЦ) , а есть только неподдержанный организационными решениями (необходимым для управления конфигурацией workflow) софт PLM.
Коллизии , возникающие из проблем управления конфигурацией - самые распространенные. Отсутствие управления конфигурацией как раз и характеризуется словами "у них там бардак". Поэтому разворачивание технологии управления конфигурацией - центральная забота при создании СУЖЦ.
Управление конфигурацией требует:
- указания метода (управлять конфигурацией можно очень и очень по-разному, есть самые разные теории на этот счёт - теории идентификации, учёта, версионирования).
- обучения людей - это дисциплина, её нужно знать, и ей нужно дисцилинированно следовать.
- разворачивания в организациях технологии: конфигурационных баз данных, справочников по кодировкам, систем версионирования и т.д.
Инструментарий
Для управления конфигурацией определения системы сейчас используют информационные системы.
6 марта 2009 в 11:10Конфигурационный менеджмент (часть1, вступительная)
- Управление проектами
Как разрабатывать большое ПО? Ни для кого не секрет, что потребность в разработке больших и сложных программных продуктов была всегда и также всегда была независимой от уровня технологий, существующих на тот или иной момент времени. Но исследуя и анализируя существующие подходы к девелопменту, я так и не смог ответить на самые простые вопросы, связанные с «правильной» разработкой качественных программ. Одним из простейших вопросов, который я перед собой ставил, был вопрос о том, как назначать номера версий выпускаемому программному продукту. Наверняка многие согласятся, что это касается не только больших корпоративных приложений, но и самых простых приложений, которые выходят из под пера начинающих программистов, школьников и студентов. Смысл назначения версий возникает тогда, когда программа перестает быть экспериментом и начинает делать что-то полезное. Но стоит заметить, что даже экспериментальным версиям программ есть смысл назначать уникальный идентификатор. Изменение номеров версий отображает последовательный подход к разработке и, с одной стороны, представляет собой соответствие выдвигаемым к разрабатываемой программе требованиям, а с другой стороны – связь с предыдущими версиями в виде общей базовой функциональности или базы исходного кода (source codebase). Мы уже не задаем вопрос о том, как разрабатывать большое ПО, а пытаемся представить себе то, как назначать версии своим программам. Да, но какая между этими вопросами связь? На самом деле очень большая.
Перед началом разработки какого либо программного проекта должно быть решено довольно много вопросов: где взять финансирование, сколько людей будет работать над проектом, какие установить сроки, какие есть риски и много-много других. Но это с менеджерской позиции. С позиции программиста решаются вопросы другого рода: проектирование архитектуры, базы данных, рисование UML-диаграмм и прочее. Но это в теории – потратить день, чтобы за 5 минут долететь. Если считать все вышеуказанные шаги этапом «0» в разработке проекта, то на практике программный проект начинается с этапа номер «1» – с разработки. Пусть это не совсем правильно, но что делать тогда, когда ни на один из вопросов, которые ставятся перед началом разработки ответить с большой степенью вероятности нельзя? Даже если такие ответы есть, в том или ином виде любой программный продукт претерпевает эволюционные изменения - требования имеют тенденцию меняться. Таким образом, любой программный проект подвергается трудно формализуемым влияниям, которые своим результатом имеют разные версии продукта, от этого никуда не деться.
Гибкие методологии (agile methodologies) известны тем, что пытаются организационными мерами решить подобного рода проблемы, и это, надо сказать получается довольно успешно. Но это организационный уровень. Программистский уровень предполагает немного другие задачи и проблемы. Нельзя сказать, что они не решаются совсем, но недостаток таких решений, на мой взгляд, заключается в том, что всеми они решаются по-разному. Даже одними и теми же людьми, но для разных проектов одни и те же задачи решаются по-разному. Для того, чтобы понять что я имею в виду и для того, чтобы выделить суть подходов к гибкой разработке с точки зрения программиста я перечислю подходы, которые обычно используются:
- Контроль версий (version control)
- Автоматизированные сборки (build management)
- Юнит-тестирование (unit-testing)
- Статический анализ кода (static source code analysis)
- Генерация документации на основе исходного кода (javaDoc, phpDoc, Doxygen итп)
- Непрерывная интеграция (continuous integration)
Как оказалось, существует отдельная дисциплина инженерии программного обеспечения, которая занимается подобного рода организационными задачами без привязки к методологиям – это конфигурационный менеджмент (configuration management). Управление конфигурациями является основной дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы программного проекта, внесенные в него изменения, а также информация про состояние отдельных задач и всего проекта в целом. Успех проекта в большой мере зависит от того, насколько налажен процесс управления конфигурациями и это может как спасти проект, так и похоронить его в том случае, если управление конфигурациями работает плохо.
Глоссарий IEEE 610 описывает управление конфигурациями как дисциплину применения технических и административных указаний (инструкций) и контроля (наблюдения) для: идентификации и документирования функциональных и физических характеристик элементов конфигураций; контроля (управления) над изменениями этих характеристик; записи (сохранения) и ведения отчетности по обработке изменений и статуса их реализации; проверки (верификации) соответствия выдвинутым требованиям.
Но это уж очень формальное определение. Чтобы дать вам представить, что же это всё означает, просто перечислю программные продукты и инструменты, с которыми программисту приходится сталкиваться по долгу службы каждый день:
- Subversion; CVS; Git; Mercurial; Bazaar; Microsoft Visual SourceSafe; ClearCase; Perforce
- Ant; Nant; Maven; Phing; make; nmake; Cmake; MSBuild; Rake
- JUnit; NUnit; CPPUnit; DUnit; PHPUnit; PyUnit; Test::Unit; vbUnit; JsUnit
- PMD; FxCop; PHP_CodeSniffer; PyChecker, lint
- JavaDoc; phpDocumentor; CppDoc; RDoc; PyDoc; NDoc; Doxygen
- CruiseControl; CruiseControl.NET; TeamCity; xinc; Atlassian Bamboo; Hudson
- Jira, Trac, Mantis, Bugzilla, TrackStudio
- Я немного расскажу об упомянутых средствах и инструментах так сказать «с высоты птичьего полета» в разрезе управления конфигурациями, попробую привести описание их места в общей мозаике средств разработки.
- Покажу наконец, какими принципами нужно руководствоваться при назначении релизам программных продуктов номеров версий, попытаюсь сделать этот вопрос более прозрачным, чем он есть (подозреваю для многих) сейчас.
Продолжение следует
Онлайн калькуляторы
