Интеграционный релиз что это
Интеграционные релизы в СберТехе
Добрый день, уважаемые хабражители!
Я расскажу о том, как происходит управление интеграционными релизами в компании «Сбербанк-Технологии», где я работаю. Хотелось бы поделиться опытом и обсудить его с коллегами по ИТ-отрасли. Подобные вещи практикуются и в других крупных ИТ-инфраструктурах – было бы интересно сравнить.
В СберТехе одновременно делается больше сотни проектов, каждый из которых может вносить изменения в несколько автоматизированных систем. Систем насчитывается несколько сотен, многие из них интегрированы друг с другом через сервисную шину. Это порождает огромное количество взаимозависимостей между проектами: доработки в одном проекте могут влиять на функционал другого. Интеграционные релизы направлены на объединение реализуемых проектов в один пул, синхронизацию их доработок и доведение всех проектов до одномоментного внедрения.
По сути, управление интеграционными релизами является частью процесса управления релизами, одного из 10 базовых процессов ITIL. Без него изменения большой ИТ-инфраструктуры практически невозможны: большинство проектов никогда бы не закончилось, пытаясь учесть все новые и новые доработки автоматизированных систем. Кроме того, одномоментное ночное внедрение минимизирует простой систем, что немаловажно для удобства клиентов.
За счет перекрытия соседних интеграционных релизов достигается равномерная нагрузка на разработчиков и других участников процесса.
Управление релизами (Release management) по ITIL
Процесс управления релизами актуален для компаний, деятельность которых связана с информационными технологиями.
Обычно работа над программным обеспечением, ИТ-системами и сервисами не заканчивается после этапа внедрения. Ведь улучшение и наращивание возможностей с учетом потребностей пользователей и roadmap продукта − неотъемлемая часть его жизненного цикла.
Понять, какие изменения необходимы на разных этапах, запланировать и реализовать их, ничего не упустив, помогает автоматизация управления релизами.
Что такое управление релизами
Релизами называют запланированные изменения, которые вносят в программное или аппаратное обеспечение.
Управление релизами по ITIL − это комплексный процесс, объединяющий планирование, реализацию, тестирование и внедрение изменений в ИТ-продукт, а также контроль их качества при дальнейшем использовании.
Зачем автоматизировать процесс управления релизами
Внедрение процесса управления релизами позволяет:
Из каких этапов состоит процесс управления релизами
Ключевые этапы процесса управления релизами
На этом этапе собираются требования к продукту от клиентов и внутренних заказчиков, анализируется актуальность предложенных изменений с учетом ресурсов, компетенций, времени на реализацию и совместимости с уже существующими функциями ПО.
Приоритетные запросы группируются и разделяются на блоки, задачи и подзадачи. Составляется подробный план релиза со сроками и контрольными точками. Указываются специалисты, которых необходимо привлечь к участию в проекте.
Организуется процесс разработки и стартует реализация намеченных функциональных изменений. Объемный по содержанию релиз разбивается на спринты и итерации.
Проводится тестирование доработок в собственной ИТ-среде. При необходимости формируются группы пользователей, которым предоставляется доступ к бета-версии для выявления критичных багов и первичной «обкатки» новых возможностей. По итогам тестирований производится финальная подготовка релиза с исправлением всех ошибок.
Осуществляется выпуск изменений, передача в эксплуатацию, документирование изменений. Выходит новая версия или сам конечный продукт. Все пользователи получают доступ к функциям, которые разрабатывались в релизе.
5. Контроль качества
После развертывания участвующая в релиз менеджменте команда подводит итоги, анализирует выполненное. Если при внедрении новых функций возникает потребность в сопутствующих доработках, специалисты фиксируют их и планируют дальнейшее усовершенствование продукта в рамках нового релиза.
Как ITSM 365 решает проблему управления релизами
ITSM 365 − это облачный сервис деск, который позволяет организовать процесс управления релизами в автоматизированном виде.
Управление релизами с помощью сервис деск дает возможность быстрее выпускать качественные обновления ПО, отслеживать выполнение намеченных планов по продуктовому развитию, оценивать загрузку и корректировать объем работ, соблюдая дедлайны. Как результат − структурированный подход к реализации изменений делает процессы развития ИТ-систем и приложений прозрачными и понятными.
«Одна кнопка, чтобы тестировать их всех». Как не упустить все интеграции из поля зрения
Привет, Хабровчане! Мы – Владимир Мясников и Владислав Егоров — представители команды интеграционного тестирования Mir Plat.Form (АО «НСПК»). Сегодня мы расскажем про разработанный и развиваемый нами инструмент автоматизации, позволивший сократить рутину во внутренних процессах команды.
Предисловие
Платёжная экосистема Mir Plat.Form включает в себя несколько десятков систем, большинство из которых взаимодействуют между собой по различным протоколам и форматам. Мы, команда интеграционного тестирования, проверяем соответствие этих взаимодействий установленным требованиям.
На данный момент команда работает с 13 системами уровня mission и business critical. Mission critical системы обеспечивают выполнение Mir Plat.Form своих основных функций, обеспечивающих стабильность и непрерывность функционирования банковской карточной системы РФ. Системы уровня business critical отвечают за поддержку предоставляемых клиентам Mir Plat.form дополнительных сервисов, от которых зависит непосредственная операционная деятельность компании. Частота выкатывания релизов в ПРОД варьируется от раза в неделю до раза в квартал, всё зависит от системы и готовности участников к частоте обновлений. В общей сложности мы насчитали около 200 релизов, прошедших через нашу команду в прошлом году.
Простая математика гласит следующее: количество проверяемых цепочек это — N-систем * M-интеграций между ними * K-релизов. Даже на примере 13 систем * 11 интеграций * 27 версий релизов получается примерно 3 861 возможных вариантов совместимости систем. Кажется, ответ очевиден – автотесты? Но проблема чуть серьезнее, только автотесты не спасут. Учитывая растущее количество систем и их интеграций, а также различную частотность релизов, всегда имеется риск протестировать неправильную цепочку версий систем. Следовательно, имеется риск пропустить дефект в межсистемном взаимодействии, например, влияющий на корректность работы платежной системы (ПС) «Мир».
Естественно, в ПРОДЕ наличие такого рода багов недопустимо, и задача нашей команды – свести такой риск до нуля. Если помните текст выше, любой «чих» влияет не только на внутренние системы Mir Plat.form, но и на участников рынка: банки, торгово-сервисные предприятия (ТСП), физические лица и даже на другие платежные системы. Поэтому для устранения рисков мы пошли следующим путем:
С одной стороны, все эти действия позволили улучшить понимание команды о тестируемых интеграциях, версиях систем и последовательности их выхода в ПРОД. С другой — все равно осталась вероятность некорректного тестирования вследствие человеческого фактора:
Стало очевидным, что этот процесс подготовки к интеграционному тестированию релизов нужно как-то автоматизировать и по возможности объединить в один интерфейс. Вот тут и появляется наш собственный велосипед-спаситель: Система Мониторинга Интеграционного Тестирования или просто СМИТ.
Какие опции хотелось реализовать в разрабатываемой системе?
1. Наглядный календарь релизов с возможностью вывода версий всех систем на конкретную дату;
2. Мониторинг окружений для интеграционного тестирования:
Что есть СМИТ
Так как система несложная, мы не стали особо мудрить с технологиями. Бэкенд написали на Java с использованием Spring Boot. Фронтенд — на React. К базе данных особенных требований не было, поэтому мы выбрали MySql. Поскольку у нас принято работать с контейнерами, то все вышеперечисленные составляющие завернули в Docker, собирая при помощи Docker Compose. Работает СМИТ быстро и так же надежно, как остальные системы Mir Plat.Form.
Интеграции
Ведение списков систем
Перед тем как в СМИТе вести календарь и мониторить состояние окружений, необходимо завести список тестируемых систем и взаимосвязи между ними. Все настройки можно произвести через веб-интерфейс:
После добавления тестируемой системы в список СМИТ:
Календарь релизов
После того, как владельцы систем или тим лиды команд разработки продуктов сообщают нам дату установки нового релиза в ПРОД, мы регистрируем этот релиз в календаре. Получается вот такая вот картина:
Можно легко заметить конфликты, где за несколько дней устанавливается сразу несколько релизов и возможна “жара”. Об этих конфликтах уведомляются владельцы продуктов, ведь ставить несколько новых версий систем в один день действительно опасно.
Также на странице с календарем имеется функция вывода версий всех систем на конкретную дату:
Стоит отметить, что при регистрации нового релиза в календаре СМИТ автоматически создает Epic структуру в Jira и релизные ветки в проектах в Bitbucket.
Состояние окружений
Еще одной очень удобной функцией СМИТа является просмотр текущего состояния конкретного окружения. На этой странице можно узнать перечень систем, включенных в окружение, и актуальность их версий.
Как видно на скриншоте, СМИТ обнаружил на хосте host-4.nspk.ru неактуальную версию System 4 и предлагает обновить её. Если нажать красную кнопку с белой стрелкой, то СМИТ вызовет Jenkins джоб на деплой актуальной версии системы в текущем окружении. Также есть возможность обновить все системы после нажатия соответствующей кнопки.
Окружения для интеграционного тестирования
Стоит немного рассказать про то, как мы задаем тестовые окружения. Одно окружение представляет собой некий набор стендов с развернутыми системами Mir Plat.form и настроенной интеграцией (на одном стенде — одна система). В общей сложности у нас 70 стендов, разбитых на 12 окружений.
В проекте интеграционных автотестов у нас есть конфигурационный файл, в котором тестировщики задают тестовые окружения. Структура файла выглядит следующим образом:
Помимо того, что данный файл необходим для работы проекта интеграционных автотестов, он также является дополнительным конфигурационным файлом для СМИТа. При запросе обновлении информации об окружениях в СМИТе отправляется HTTP запрос в API нашего bitbucket, где мы храним проект с интеграционными автотестами. Таким путем СМИТ получает актуальное содержимое файла конфигураций из master ветки.
Запуск тестов
Одной из целей создания СМИТа было максимальное упрощение процедуры запуска интеграционных автотестов. Рассмотрим, что же у нас получилось в итоге на примере:
На странице тестирования системы (в данном примере — System 3) можно выбрать перечень систем, с которыми нужно проверить интеграцию. После выбора нужных интеграций и нажатия на кнопку “Запустить тестирование”, СМИТ:
1. Сформирует очередь и последовательно запустит соответствующие Jenkins джобы;
2. мониторит выполнение джоб;
3. меняет статус у соответствующих задач в Jira:
Вывод
СМИТ был создан для минимизации рисков интеграционного тестирования, но нам как команде хотелось бОльшего! В частности, одним из желаний было, чтобы по одному нажатию кнопки автотесты запускались с правильным тестовым окружением, проверялось все в нужных интеграционных соответствиях, задачи в Jira сами открывались и закрывались вместе с отчетами. Такая утопия автотестеров: скажи системе, что проверить, — и иди пить кофе 🙂
Подведем итог, что у нас получилось реализовать:
О планах на будущее
На данный момент система проходит закрытое бета тестирование среди непосредственных участников команды интеграционного тестирования. Когда все найденные дефекты будут устранены, и система стабильно будет выполнять свои функции, мы откроем доступ сотрудникам смежных команд и владельцам продуктов для того, чтобы у них была возможность самостоятельно запустить наши тесты и изучить результат.
Таким образом, в идеальном сценарии, всё, что потребуется сделать для проверки соответствия системы требованиям по интеграции — зайти в веб интерфейс СМИТ, обновить через него необходимую систему, выбрать все галки и запустить тесты, а затем проверить, что они все выполнены успешно. Автоматически будут созданы задачи, заполнены allure-отчеты, проставлены соответствующие статусы этим задачам.
Управлять релизом просто: правила и этапы release management
Релиз является одним из самых важных и ожидаемых событий в жизненном цикле продукта. Приготовления к релизу могут занимать много усилий и времени, участия всей команды и заинтересованных сторон. Хорошо, если выпуск продукта или его версии проходит гладко и становится настоящим праздником. Но бывает иначе. Что из себя представляет эффективный релиз-менеджмент и как менеджерам продукта научиться его секретам?
Релиз связан с запуском нового продукта/сервиса/услуги или набором новых функций, изменений, которые становятся доступны клиентам или пользователям и обеспечивают новую продуктовую ценность.
Часто релиз состоит из ряда решений по устранению проблем и улучшений предоставляемых услуг, может включать изменения в ПО. На самом деле, это довольно значимое событие как для внутренних команд, так и для целевой аудитории.
Управление релизами помогает командам планировать свою работу и видеть конечный результат, а для клиентов это, своего рода, гарантия качества и получения новой ценности.
Хорошо подготовленный релиз — это не только предоставление доступа к новым техническим возможностям продукта. Это конечная дата, когда ваша команда может предоставить новый пользовательский опыт, поддержать и развить взаимодействие с ним.
Релизы должны включать все дополнительные задачи и активности, такие, например, как обновления на официальном сайте и в социальных сетях, обучение команды поддержки, обновление всех маркетинговых материалов и т. д.
Основная цель управления релизом — создавать, тестировать и доставлять новые возможности, которые будут удовлетворять все продуктовые требования и намеченные цели.
Продуктовым командам стоит тщательно планировать релизы, поскольку они являются новым предложением, которое ожидают клиенты.
Что включает процесс управления релизом?
Понимание процесса управления выпуском продукта может отличаться у разработчиков и нетехнических специалистов. Важно учитывать все аспекты релиза и прислушиваться к мнению каждого члена команды.
Процесс управления релизом может включать следующие этапы:
В управлении релизом продукта могут участвовать практически все члены команды.
Product manager и Project Manager
Менеджеры продуктов и менеджеры проектов несут основную ответственность за релиз. Функционал product manager project и manager отличается, но миссия у них одна — выпустить продукт и представить его клиентам в идеальном виде.
Разбработчики
Команда разработки — это ключевые игроки в управлении релизом, поскольку они участвуют в большинстве процессов в жизненном цикле продукта. Они оценивают изначальные затраты и время, определяют основные требования, создают документацию и разрабатывают функциональность. Они принимают главные решения о том, что можно сделать и что не нужно, а также сколько времени это займет.
Маркетинг
Маркетологи всегда должны “держать руку на пульсе” и быть в курсе того, чем живут конкуренты. В управлении релизом им важно тесно отрудничать с sales-менеджерами для получения новых и удержания существующих клиентов.
Тестировщики
Тестировщики работают вместе с разработчиками. Их задача — тестировать результаты исследований и разработки, основываясь на установленных критериях. Продукт не придет к релизу, пока не будут учтены все замечания и критерии прохождения тестирований.
Служба поддержки
Support-команда или отдельный специалист поддержки первыми получают сообщения, елси что-то пошло не так. Они должны понимать и знать все о релизе и должны быть должным образом подготовлены на всех уровнях еще на стадии планирования.
Помимо этих основных ролей, к управлению релизом могут привлекаться и другие специалисты: отдела закупок, финансисты, sales, биллинг, system engineering и др.
Почему нужно внедрять процесса управления релизам?
Что такое Release Notes в процессе управления релизом?
Release Notes — это примечания к версии продукта, в которых описываются изменения между выпускаемой и предыдущей версиями этого продукта. Такой документ может составляться для пользователей и для внутренних команд: тестировщиков, маркетологов, службы поддержки.
Когда используются примечания к релизу?
Примечания к релизу распространяются вместе с продуктами. Иногда — когда продукты все еще находятся в разработке или тестировании. Документ может быть доставлен клиентам при выпуске обновления (для продуктов, которые уже были использованы клиентами).
Вы можете найти различные варианты написания Release Notes, поскольку для этого документа нет единого стандарта или формата. В разных компаниях менеджеры продуктов, тестировщики и разработчики, которые обычно ответственны за написание примечаний, обычно используют свои собственные шаблоны.
Вот как выглядит страница с примечаниями к релизу у Firefox:
Как писать примечания к релизу?
Содержание документа зависит от типа релиза. Вот пример основных пунктов:
Заключение
Управление релизом во многих компаниях становится отдельным самостоятельным процессом, который сообщает заказчику дату выпуска продукта и основные этапы его развития. Заказчик участвует в приоритизации и вовлечен в определение содержания релиза.
Процесс позволяет менеджерам продуктов и команде своевременно оценить загрузку и управлять объемом работ, доставлять изменения в срок. Управление релизами позволяет собирать собственную статистику, с которой удобнее в дальнейшем обосновывать запросы на дополнительные ресурсы.
Если вы хотите детальнее разобраться в теме release management и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)
Релизим фронтенд несколько раз в день
Меня зовут Петр Солопов, я руковожу фронтенд-разработкой в SuperJob. В этой статье хочу рассказать об опыте ежедневных релизов у нас в компании, зачем мы это делаем и почему это не так страшно, как кажется.
История разбита на пять частей: что нас к этому привело, как это сделать, сколько нужно тестов и каких, что следует автоматизировать в процессе деплоя и как мониторить продакшн.
Немного контекста
Каждый день нашим сервисом пользуется более одного млн активных пользователей. В команде работает 62 инженера, в том числе 10 фронтенд-разработчиков.
Мы пишем большое SPA с поддержкой серверного рендеринга, в котором более сотни роутов. Под капотом используем Node.js для SSR, пишем на React-Redux без бойлерплейта. Весь код у нас статически типизирован с помощью Flow и TypeScript, собираем проект Webpack’ом.
Инструменты
Зачем нужны ежедневные релизы и что для этого надо
Первоначально у нас были нерегулярные релизы, каждый из которых был целым событием. Постепенно мы пришли к одному релизу в неделю, что тоже нас не устраивало. Сейчас у нас два релиза в день, все автоматизировано и ничего не болит. Есть только направления для улучшения.
Начну с самого простого вопроса: почему мы вообще пришли к ежедневным релизам? Ответ очевиден: бизнес хочет «фичи на бою». Таким образом он оценивает динамику разработки. Для разработчиков это тоже удобно. Если система построена на ежедневных релизах, а значит, на небольших изменениях, намного проще и быстрей находить проблемы.
Минимальный джентльменский набор, который понадобится:
автоматизация процессов деплоя;
онлайн мониторинг продакшена.
Далее про все это более подробно.
Настраиваем три вида тестов
Начнем с тестов нескольких видов: юнит-тестирование, скриншотные тесты и интеграционные тесты.
Юнит-тесты
У нас написано более 1000 юнит-тестов. Используем тестовый фреймворк mocha. Также есть метрика покрытия кода тестами, но к ней относимся без фанатизма. Достаточно определенного не слишком высокого порога, ниже значений которого тесты упадут.
Скриншотные тесты
Так как на фронтенде мы пишем интерфейсы, то нужно проверять, что верстка нигде не ломается и компоненты выглядят именно так, как мы задумывали. В этом помогает скриншотное тестирование.
В рамках скриншотного тестирования у нас тоже более 1000 тестов. Они проходят за 11 минут в CI. Мы даже написали собственное решение, которое занимает порядка 100 строк кода (чуть подробнее про него — ниже). Начать стоит с того, что у нас своя библиотека компонентов на React и есть витрина, в которой эти компоненты представлены. Этой витриной пользуются разработчики, дизайнеры и менеджеры.
Витрина компонентов
На изображении выше представлена страница одного из компонентов — «Баннер». Таких компонентов в нашей витрине сотни. У каждого есть описание и интерактивные примеры. Мы подумали, что раз у нас уже есть место, где находятся все компоненты с разными состояниями, то почему бы его и не «фотографировать».
Вернемся к нашему решению. С помощью Playwright (безголовый браузер) и тест-раннера от этой же команды запускаем скриншотные тесты. Можно использовать любой тест-раннер, который умеет параллелить и параметризировать тесты. Без параллелизации скриншотные тесты на больших объемах могут проходить несколько часов. А параметризация нужна, чтобы написать один тест, но с разными данными, т.к. действия с каждым компонентом будут одни и те же: зайти на страницу компонента, найти интерактивный пример по индексу, сделать скриншот:
Далее скриншот сравнивается с существующим изображением. Если вдруг что-то пойдет не так, то мы увидим актуальное изображение, ожидаемое и разницу. В данном случае, например, исчез крестик с баннера, и на дифе это сразу видно:
Актуальное изображение и диф
Интеграционные тесты
Все тесты, о которых шла речь, запускаются в CI на ветках автоматически. А когда тесты успешно прошли на ветке и появилось два аппрува в пулл-реквесте, то ветку можно мерджить. Теперь о том, куда мерджить и как код попадает в продакшн.
Автоматизация процессов деплоя
Мы работаем по классическому Git flow. Есть ветка master (код из мастера находится на продакшн), и есть ветка dev, где ведется основная разработка, и от нее делаются фиче-ветки.
Также есть релизная ветка. Это ветка, которая создается от ветки dev и потом вливается в master и dev. Таким образом на продакшн поставляется новый код.
Тут есть что автоматизировать. Важно понимать, какое сейчас состояние у релиза. Для этого у нас есть отдельный канал в слак, куда приходят отбивки по текущим состояниям. Сначала приходит сообщение, что релиз зафиксировался. Это происходит автоматически два раза в день. Далее приходит сообщение, что на релизной ветке успешно прошли все тесты.
Git flow и уведомления
Затем приходит уведомление, где отмечается дежурный фронтенд-разработчик. Его задача — пройти по ссылке и нажать кнопку «Катим релиз». После этого релизная ветка вливается в master и dev.
Все, что вливается в master, автоматически начинает собираться и раскатываться на продакшн, о чем также приходит уведомление: «У нас запланирован деплой». После того как все собралось и успешно раскатилось на боевые сервера, нам приходит уведомление, что все прошло успешно.
Онлайн мониторинг
Выше вкратце описан процесс попадания новых изменений на бой. Но это еще не все. Нужно убедиться, что после релиза все работает. В этом нам помогает мониторинг. Как я говорил в начале, у нас сервер на Node.js. И нам нужны стандартные метрики сервера.
Мониторинг сервера
Среди метрик — количество 200-х, 300-х, 400-х, 500-х ошибок и другие данные: сколько потребляется памяти и так далее. Также на графиках вертикальной зеленой линией отмечается релиз и есть соответствующие значения за предыдущий период. После релиза нас больше всего интересуют ошибки.
Мониторинг ошибок
Чтобы видеть детали ошибок, у нас настроен Sentry — клиентский и серверный. Он нужен для мониторинга ошибок в рантайме. Там можно отфильтровать проблемы по релизу и убедиться, что нет всплеска ошибок. Если появляется новая ошибка или какой-то аномальный всплеск, также сразу приходит уведомление в слак.
Важно чтобы релизы не ухудшили производительность. Для этого у нас есть отдельный дашборд в графане. Слева направо идут следующие графики: сколько страница формируется на сервере, сколько парсится и загружается JavaScript и как быстро страница становится интерактивной. Снизу это дублируется для мобильного веба, потому что у нас два приложения: Desktop и Mobile.
Мониторинг производительности
Также у нас настроены ночные тесты производительности Lighthouse-ом. Они довольно долгие из-за большого количества проверяемых страниц. Тут мы уже постфактум убеждаемся, что ничего не сломали.
Lighthouse CI
Проблемы в релизе
Мониторинг может сообщить о том что после релиза возникли проблемы. План действий зависит от масштаба трагедии. Если проблема локальная и не влияет на базовые сценарии пользователя, то возможен хотфикс.
Если проблема критическая, то предусмотрена возможность переключения на предыдущий релиз в считаные секунды. К счастью, мы этим пользуемся крайне редко.
Итоги и планы
Ежедневные релизы — это не страшно, когда код покрыт тестами, настроен онлайн мониторинг, вся рутинная работа с деплоем автоматизирована и есть мгновенная возможность откатить изменения.
В планах — запускать тесты производительности на пулл-реквестах, сделать канареечные релизы и прийти к полностью автоматическому развёртыванию релиза без участия разработчика.