Highway to Continuous Integration

Обо мне

Инженер по качеству в команде Continuous Delivery

api.2gis.ru

• Справочник организаций
• Геоданные
• Карты
• Транспорт (скоро)

Справочное API

• Версии 1.3 и 2.0
• 7 приложений + Core на Yii Framework (PHP)
• Функциональные и юнит-тесты
• Git Flow
• 20 смежных команд

Проблемы

• Разработчики коммитят бажный код
• Тестировщики не находят баги или не успевают проверить фичу

Последствия

• Узнаем о багах при подготовке к релизу
• Релиз затягивается или переносится

Continuous Integration —

не решит всех проблем разработки, но позволит выявлять баги на этапе программирования фичи

Что у нас есть

• Ветка с новой фичей
• Тесты
• Система деплоя

Этапы интеграционной сборки

1. Деплой фичи
2. Выполнение тестов
   • Когда все хорошо, сливаем фичу в мастер
   • Когда что-то упало, сообщаем о проблеме

Время этапов сборки

• Деплой за 3 минуты
• Тесты за 5 часов 57 минут

Анализ выполнения тестов

• Максимальное время выполнения одного теста 2 минуты
• Среднее время выполнения одного теста 1,5 секунды
• PHPUnit использует одно ядро (из 16) процессора

ParaTest

github.com/brianium/paratest
Поддержка параллельного выполнения тестов на PHPUnit

Пример

			$ paratest -p 16 --phpunit ./phpunit \
  -c ./phpunit.xml ./tests
		

Ищем компромисс

• Долгая интеграция, но стабильный мастер
• Быстрая интеграция, но возможные баги в мастере

Исключаем тесты

• Оставляем только приоритетные тесты
• Оставляем только формат JSON (убрали JSONP и XML)

Итого: 1500 тестов

Еще быстрее?

Если не было изменений в окружении, то достаточно обновить только приложения

Деплой окружения и приложений

• Мелкие правки с помощью Phing (только приложения)
• Большие правки с помощью Chef (приложения + окружение)

Лень побеждает

У нас есть автоматизированная сборка, но после нее приходится самому писать в JIRA о смене статуса фичи

Интеграция с JIRA

• Комментарий в тикете об автоматическом мерже веток
• Метка у тикета при попадании в мастер

JIRA REST API Client

github.com/chobie/jira-api-restclient
API-клиент для JIRA на PHP

Пример (PHP)

			$client->addComment($jiraIssue, $jiraComment);

$client->editIssue($jiraIssue, [
  'fields' => ['labels' => $labels]
]);
		

Интеграционная сборка в работе

			Feature Branch -> Deploy -> Priority Tests
  -> Merge to Master -> Mark Issue in JIRA
		

Профит

Разработчик спустя три минуты после готовности фичи может слить ее в мастер

Но...

Мы все также неуверенны в мастере

Регрессионная сборка

			Master Branch -> Deploy -> Full Tests
		

Регрессия перед релизом

			Master Branch -> RC -> Deploy -> Full Tests
  -> Merge to Stable -> Mark Issues in JIRA
		

Профит

Мастер становится стабильным спустя половину дня вместо пяти

Как так?!

Упала миграция на бою, хотя регрессия прошла успешно

Задача

Перед регрессией нужно полностью восстанавливать исходное состояние окружения

Куда поместить окружение

• Open Stack
• Virtual Box
• Docker
• Другие технологии контейнеризации и виртуализации

Архитектура в Open Stack

• API-нода
• Нода с тестами
• Любая нода по требованию за 1 минуту

Обновленная регрессия

			... -> Revert VM -> Deploy -> ... -> Update Snapshot
		

Профит

Во время регрессии деплоим так же, как на бою

Понедельник день тяжелый

Вышел новый сотрудник, начал настраивать рабочее окружение и вылетели ошибки во время разворачивания API

Сборка деплоя с нуля

			VM Up -> Deploy -> Import Data -> Tests -> VM Destroy
		

Профит

Мы уверены, что в любое время можем развернуть API без ошибок

Итого

1. Интеграционная сборка
2. Регрессионная сборка
3. Сборка деплоя с нуля

Итого

Выявляем баги не при подготовке релиза, а по мере готовности фич. Сборки падают, а значит выполняют свои задачи.

Результат

• Мы находим проблемы спустя три минуты вместо пяти дней
• Мастер становится стабильным спустя половину дня вместо пяти

Вывод

Continuous Integration помогает выявлять баги на этапе программирования фичи