ИТ Компании с настронными надежными инструментами релиз-менеджмента сегодня имеют очень весомое конкурентное преимущество. В этой статье Surinderpal Kumar рассказывает о трех основных трендах в управлении релизами, от которых может выиграть любая ИТ компания.
В связи с увеличением давления со стороны рынка, компании всеми силами стараются выпускать их продукты раньше конкурентов. Такие частые релизы позволяют командам проверять функциональность раньше и легче выявлять ошибки. Кроме того, меньший релизный цикл дает большую гибкость, позволяя вносить непредусмотренные изначально изменения без лишних затрат. В результате, компании с такой системой релизов получают значительное конкурентное преимущество.
Процесс внедрения таких методик, тем не менее намного проще описать словами, чем реально внедрить в компании, поскольку с каждым днем разработка софта становится все сложнее и сложнее. Как минимум из-за того что постоянно появляется все больше устаревающего кода, меняются ресурсы, появляются команды, распределенные по всему миру, увеличивается количество поддерживаемых платформ. В этой статье я расскажу о трех основных трендах, от которых может выиграть любая ИТ компания.
Первый тренд: внедрение гибких методологий на уровне ядра, включая автоматизацию. Просто каждое утро проводить стендап-митинги будет недостаточно. Да, планирование спринтов и итераций вместе с ревью и ретроспекцией тоже важные элементы для успешных релизов. Однако, для того чтобы выпустить существенные, значимые истории или фичи за отведенное на спринты время, компании вынуждены инвестировать в автоматизацию.
Отсутствие автоматизации приводит к нагрузке на вашу команду разработчиков и вносит человеческий фактор в ваше окружение, что влияет как на скорость и эффективность работы команды. Правильная автоматизация сформирует неизменный повторяемый процесс, уменьшающий количество ошибок и время релиза. Гибкие методологии — будь то scrum или lean — все крайне рекомендуют автоматизировать сборку, автоматизацию тестов, автоматизацию отгрузки/деплоя, и автоматизацию ревью/обратной связи. Особенно важно, что автоматизация освобождает команды разработки от излишней работы по ручной конфигурации, позволяя сосредоточиться на коде и разработке продукта.
Например, как только разработчик коммитит изменения в систему контроля версий, изменения автоматически интегрируются с остальными модулями. Затем уже собранное приложение автоматически размещается на тестовой среде. Собранные модули затем автоматически деплоятся на тестовую среду. Если были изменения в платформе или окружении, эти изменения автоматически билдятся и переносятся на тестовую платформу. Следующим шагом автоматически проводятся тесты применимости такой сборки, в которые также входят тесты производительности, надежности и емкости. Разработчики и/или руководители уведомляются только в случае ошибок. Однако, основной акцент остается на разработке ядра, а не просто на дополнительной излишней активности. Конечно, какие-то ручные проверки в любом случае останутся, их нужно будет проводить команде релиз-менеджеров, чтобы переходить к следующим шагам, но почти вся деятельность в рамках процесса деплоя может быть более или менее автоматизирована.
По мере прохождения QA тестов, релиз версии продукта автоматически передается в релизный репозиторий из которого новая версия может быть запулена автоматически другими системами или может быть загружена клиентами. Существует целый ряд технологий, доступных на рынке в каждом из этих разделов, включая автоматизацию билдов (например Ant, Maven, Make), непрерывную интеграцию (Jenkins, Cruise Control, Bamboo), автоматизацию тестирования (Silk Test, EggPlant, Test Complete, Coded UI), и непрерывный деплой (Bamboo, Prism, Jenkins). Внедрение best practices обычно требует стратегического планирования и инвестиций времени на ранних стадиях вашего проекта. Но это уменьшит организационные расходы и расходы на внедрение изменений на последующих стадиях.
Второй тренд — использование виртуализации и облачных платформ в качестве разработческой и тестовой среды. Сегодня большая часть софта собирается с поддержкой нескольких платформ, будь то операционные системы, сервера приложений, базы данных или интернет-браузеры. Команды разработки нуждаются в тестировании их продуктов во всех этих окружениях до того как выпустить их на рынок.
Однако, возникает трудность с созданием всех этих сред, также как и их поддержка. Эти трудности повышают сложность, особенно в связи с тем что команды разработки и тестирования становятся все более географически распределенными. В таких условиях, использование виртуализации и облачных платформ может быть очень удобным, и такие платформы в последнее время широко развернулись в ИТ отрасли.
В некоторых компаниях, команды релиз-менеджеров начинают переносить автоматизацию деплооя на виртуализированные и облачные платформы. В этом случае, точно также, как мы поддерживаем историю изменений кода и конфигурации приложений, точно также мы поддерживаем историю версий всех поддерживаемых платформ.
Например, ранее мы описали процесс проверки кода разработчиком, и автоматического запуска билда и деплоя на необходимые тестовые среды. Похожим образом, если релиз или билд-инженеры меняют конфигурацию целевой платформы (ОС, БД, или настройки сервера приложений) — вся платформа целиком может быть сбилдена и образ системы создается и деплоится на соответствующие платформы. Другими словами, если вы используете виртуализацию VMWare, виртуальная машина автоматически разворачивается из образа базовой операционной системы, подходящие конфигурации выкладываются и остальная часть платформы и компонентов приложения деплоится автоматом.
То же самое касается и облачного окружения (как IaaS, так и PaaS). Как только появляются новые конфигурации — поднимается новый инстанс, конфигурируется как среда разработки и тестовая среда. Это критично для производительности, иначе это может занимать недели чтобы адаптироваться к изменениям конфигурации. С автоматизацией, процесс становится повторяемым, быстрым, и нет никаких подводных камней в коммуникации между разными командами разработки.
Третий тренд — использование распределнных систем контроля версий. Подобные системы, как git, mercurial, perforce — становятся все более и более популярными благодаря той гибкости, которую они дают командам, чтобы взаимодействовать на уровне кода. Фундаментальная основа таких систем заключается в том, что каждый пользователь держит у себя версию репозитория со всей историей на своем компьютере. Нет необходимости в отдельном мастер-репозитории, однако большая часть команд использует его все равно как best-practice. Распределенные системы позволяют программистам работать оффлайн и коммитить изменения локально.
Как только разработчики завершают свою часть, они пушат их изменения в центральный репозиторий как RC. DVCS предоставляют фундаментально новый подход взаимодействия, такой что каждый разработчик может отправлять свои изменения часто, без воздействия на основную базу кода или транк. Это очень полезно, когда команды исследуют новые идеи или эксперементируют.
DVCS становятся удобными для команд разработчиков, которые используют гибкую основанную на фичах стратегию веток. Это воодушевляет разработчиков продолжать работать над их ветками (фичами) до готовности, полностью тестировать изменения локально, затем загружать их в релизную цепочку. В этой схеме, разработчики могут работать и мержить друг с другом фичи в локальной копии репозитория.
Только после стандартных ревью и QA тестов — изменения мержатся в главный репозиторий. Если разработка вашего софта включает в себя несколько проектных команд, распределенные команды или разработку основанную на фичах — DVCS обязательно нужно принять во внимание.
Внедрение этих трех главных трендов в релиз-менеджменте создает очень неплохой задел на будущее для любых ИТ компаний.