En

JazzTeam Software Development Company

Agile Java Development

CI/CD для инженерного приложения

CI-CDКраткое описание проекта

Проект представляет собой систему моделирования поведения физического объекта в заданных условиях. Команда JazzTeam вошла в уже функционирующий проект с целью повысить стабильность продукта и усовершенствовать процессы разработки.

Одной из самых важных и сложно решаемых проблем на проекте являлось отсутствие стабильности. Поставки были нерегулярными, было сложно предсказать поведение приложении при изменении кода. Поэтому первым делом СЕО JazzTeam было принято решение внедрять автоматизированное тестирование в рамках CI/CD системы. Основными причинами внедрения автотестирования являлись следующие:

Важным фактором, влияющим на всю систему CI/CD является то, что каждый экземпляр приложения уникален, имеет свой уникальный серийный номер и уникальный аппаратный usb ключ защиты. Это накладывает следующие ограничения:

Continuous Integration и Continuous Delivery

В рамках Continuous Integration основной целью являлось создание ежедневной автоматической проверки качества через unit и ui тестирование. Нужно это для достижения следующих важных стратегических целей:

  1. Сделать так, чтобы практически в любой момент времени был работоспособный билд приложения, содержащий в себе последние изменения.
  2. Сделать приложение стабильным. Добавление новой функциональности не должно ломать продукт.
  3. Уменьшить трудоемкость операций по багфиксингу и поставке новых приложений.

В рамках Continuous Delivery основными целями являлись:

  1. Автоматизация процесса поставки;
  2. Снижение влияния человеческого фактора;
  3. Улучшение процесса тестирования уже готовых экземпляров приложения перед их отправкой.

Постановка процессов

Для внедрения практики CI/CD также требовалась постановка управленческих процессов. Организация процесса работ – от постановки задач до тестирования, внедрение Scrum, изменение мышления команды.

До прихода JazzTeam нормальной практикой на проекте было – сделать быстро, без документации и проработанного тестирования. Естественно, при этом приходилось тратить массу времени на поддержку из-за регулярных проблем при поставках. После нашего прихода, уже через 3 месяца, команда разработки, сохранив скорость создания нового функционала, начала сокращать технический долг и вести необходимую документацию. Как результат количество проблем при поставках существенно сократилось.

Обязательным этапом при разработке нового функционала стало его покрытие unit-тестами и ui-автотестами.

Ключевые достижениями на проекте за первые полгода:

Unit-тестирование и интеграционное тестирование

Хорошая организация процесса тестирования позволила изменить мировоззрение команды на процесс разработки. Теперь правилом хорошего тона в команде считается при устранении бага полностью покрыть этот участок кода тестами, чтобы устранить саму возможность повторного появления бага. Также, как уже упоминалось выше, при серьезном вмешательстве в уже работающий компонент стало best practice вначале покрыть его тестами и только после этого вносить туда изменения.

Так как система работает с научными данными, то одним из важных направлений тестирования стало активное применение data driven тестов. Таким образом мы смогли вовлечь в процесс тестирование всю команду проекта.

После каждого спринта фиксируются метрики по изменению покрытия кода, таким образом отслеживается тренд покрытия кода. В качестве референсных метрик используем два ключевых для нас параметра: покрытие строк кода и покрытие условий.

Прогресс не очень быстрый, так как у проекта очень большая база legacy кода – несколько сотен тысяч строк кода. И поэтому за два месяца покрытие увеличилось только на 2 процента. Однако в абсолютных числах количество unit-тестов увеличилось на 25%. Конечно, это не самые впечатляющие цифры, однако главной целью мы ставили изменение подхода команды к написанию unit-тестов и написание интеграционных ddt-тестов. И данная цель нами достигнута!

UI-тестирование

Процесс внедрения ui-тестирования начался с того, что командой было проведено практическое исследование по выбору фреймворка для ui-тестирования. Суть исследования была в том, чтобы выбрать два фреймворка по ui-тестированию и написать на каждом из них несколько ui-тестов. После сравнить результаты и остановится уже на одном. В рамках данного проекта мы выбирали из бесплатных фреймворков Appium и White. По итогу практических испытаний мы остановились на фреймворке White.

Процесс был организован следующим образом – на задачи по написанию ui-тестов разработчик выделял 5 часов в неделю. Результаты каждый день отслеживались на стендапе и вносились в специальную таблицу, которая в распечатанном виде находилась возле канбан доски.

На первом этапе были написаны только Smoke ui-тесты (базовые, важнейшие), которые, однако, позволили нам проверить работоспособность готового экземпляра приложения для заказчика в автоматическом режиме, а не вручную, как раньше.

На втором этапе мы внедрили в качестве одного из критериев готовности фичи к тестированию написание ui-теста. Это позволило нам, по мере разработки новых фич, постепенно покрывать весь функционал приложения ui-тестами.

Полностью новой практикой для проекта стало создание тестового экземпляра приложения с включенной аппаратной защитой. Одновременно с этим прошивается тестовый usb-ключ защиты. После чего тестовое приложение инсталлируется на отдельную машину и уже далее ui-тестами тестируется полностью готовое приложение в среде эксплуатации. Это позволило выявлять возможные дефекты на более ранней стадии. Ускорило процесс разработки и сделало его более прозрачным и предсказуемым.

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

Релиз-менеджмент

Внедрение Continuous Delivery позволило очень сильно упростить процесс формирования дистрибутивов. Формирование нового экземпляра приложения может быть сделано любым пользователем, а не только разработчиком.

Кроме этого автоматизированное тестирование новых экземпляром приложения позволило существенно увеличить производительность команды и дало возможность выпускать релизы в 2 раза чаще.

Технологии:

Stack: .NET, C#, C++, Managed C++
Infrastructure: Windows, Jenkins
Test Automation libraries: Appium, White

Особенности проекта:

Результат проекта:

После внедрения CI/CD мы достигли следующие результаты:

  1. Постоянно актуальную основную рабочую ветку приложения с работоспособным билдом приложения.
  2. Существенно уменьшили трудоемкость операций по багфиксингу и поставке новых экземпляров приложений.
  3. Существенно снизили влияние человеческого фактора с помощью автоматизации поставки и ежедневном автотестировании.

Достижения компании на проекте:

Скриншоты