Метка: Release management

Как и во многих крупных компаниях, наш корпоративный ИТ ландшафт состоит из информационных систем, таких как система управления отношениями с клиентами (CRM), система самообслуживания, биллинговая система и т.д. Всего их в CMDB насчитывается несколько сотен. Каждая система включает в себя несколько программных компонент. Это и базы данных и JEE приложения, толстые клиенты и web-интерфейсы. До пришествия виртуализации каждая система развертывались на своем наборе оборудования. Впрочем, и сейчас основные системы развернуты на закупленных специально для них серверах.

Не удивительно, что ИТ система является основным элементом управления. К ИТ системам привязываются запросы на изменения (Request for Change, RFC). Системы являются основной единицей процесса управления релизами. Т.е. для каждой системы развивается своя ветка релизов. Все планирование, разработка, тестирование и развертывание ведется в границах систем. Версии приложений попросту совпадают с релизами. Мы не уникальны. Многие компании развивают свою ИТ-инфраструктуру примерно так же. Но в какой-то момент это становится проблемой. Сначала проблемой ИТ архитектуры, а вскоре и проблемой всего ИТ.

На днях листая перед сном ITIL я пытался найти ответ на вопрос почему релиз может включать в себя только одну ИТ систему. Честно говоря, в явном виде такой рекомендации я не нашел. В чем недостатки привязки релиза к одной конкретной ИТ системе? Все очень просто. Традиционный цикл выпуска программного обеспечения ограничивается фазами анализ->проектирование->разработка->тестирование->развертывание. Однако в большинстве современных компаний изменения в ИТ носят комплексный характер, затрагивают сразу несколько систем (см. примечание). Такие работы, как согласование интерфейсов, интеграционное тестирование, конфигурирование приложения (это когда вместо абстрактных интерфейсов, администраторы прописывают реальные ip-адреса web-сервисов и connection strings баз данных), пользовательское тестирование (UAT), разработка архитектуры, в конечном счете =) и управления конфигурациями – остаются за бортом процесса.

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

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