Continuous Integration - от простого к сложному Александр Сербул Руководитель направления контроля качества интеграции и

Практика XP, но можно использовать отдельно Для средних и крупных проектов Возможность делать частые релизы Снижаем риски срыва сроков Автоматизируем рутину В результате – Клиент доволен Зачем ?

Обзор Непрерывный процесс тестирования и сборки

Обзор Автоматизируем все, что можно

Обзор

Используем систему контроля версий: git, mercurial, svn, bazaar Добавляем модули, компоненты, шаблоны Ядро - можно не добавлять Создаем ветки, систему аудита и политики коммита Вешаем обработчики событий – hooks Комитим часто, лучше – раз в день Система контроля версий

Ветка 1 Разработчик 1 Разработчик 2 Разработчик 3 Ветка 2 Ветка 3 Ветка DEV Изменения в ветки DEV/TESTING переносит опытный разработчик Вед. разработчик Серверы разработки Ветка TESTING Ветка PRODUCTION Серверы тестирования Вед. разработчик Тестировщик 1 Тестировщик 2

Тесты нельзя усложнять Можно не использовать PHPUnit, Simple Test Пишите тестируемый код Mock-objects – когда использовать «Отстреливайте» фанатиков Модульные тесты

Машины должны быть идентичны боевым Данные в БД тоже, либо «похожи» Тщательно продумываем схему тестового и нагрузочного стендов Серверы тестирования

Тестовая конфигурация === «боевой» MySQL, v7 «Боевой» сервер Точная копия Apache, v2 PHP, v3 Модули: apc v4, xdebug v5, curl v6… «1C-Битрикс: Управление сайтом», v1 Bash, v8 Perl, v9… другой софт для проекта… CPU, диски, рейд, память, опции ядра Тестовый сервер или конфигурация тестовых серверов, идентичная «боевой»

Важность идентичности тестовой конфигурации «Тестовая конфигурация»: баги находите Вы «Боевая конфигурация» минус «Тестовая конфигурация»: баги находит Клиент

Обязательные и «периодические» шаги deployment 4. Модульное тестирование Тестовая конфигурация 5. Функциональное тестирование 6. Нагрузочное тестирование 2. Обновление БУС «Боевая» конфигурация 3. Обновление кода и БД тест. проекта 1. Обновление системного софта Обновление БУС 1-1. Обновление системного софта Репозиторий кода (SVN, mercurial, git, bazaar) 7. Обновление кода и БД «боевого» проекта Конфигурация для разработчиков Коммиты 0-1. Резервное копирование перед обновлением

Нелепости с боевым «железом» Использование самодельных серверов подешевле Десктопные диски в серверах/рейдах База данных – на диске без … рейда Сложные типы рейдов, которые могут тормозить и трудно восстанавливаются – raid5 и т.п. Рейд под БД с кэшем записи … без батарейки Железо без платы мониторинга, неясно что с температурой, вентиляторами и т.п. Отсутствие расходных материалов – дисков и т.п.

Обновления системного софта - риски Использование «нестабильного» дистрибутива linux/unix Несертифицированная для железа операционная система Близкое окончание официального срока поддержки дистрибутива – готовимся к перезду и глюкам Десктопный дистрибутив на серверах «Левые» репозитории пакетов – кастомные любительские сборки, «ломающие» систему при обновлении Конфигурация серверов – у уволившегося «Васи» была в голове… Софт устанавливают все, кому захочется. Бардак с правами на боевые сервера. Сложно сделать бэкап боевого сервера.

Обновления системного софта - рецепты Используем проверенные временем, стабильные (stable) дистрибутивы: RedHat, CentOS, Debian … Выбираем дистрибутив с увеличенным сроком поддержки >=5 лет – LTS… Не устанавливаем «левые» репозитории пакетов Не собираем софт из исходников, если не собираемся поддерживать!! Изучаем changelog пакетов перед обновлением Обновлять можно прямо на бою, после обновления тестовой машины Продумываем как обновлять ядро – требуется перезагрузка Для подстраховки можно сделать LVM-снепшот Конфиги серверов – под контролем версий Доступа на сервера нет ни у кого, кроме админа

Обновление БУС - риски Не проверяются обновления БУС на тестовом сервере Не делаются бэкапы перед обновлением на «бою» Если модифицировано ядро, то проект может сломаться – тестируем на тестовом На «бою» может изменяться структура БД – новые индексы на большой объем данных

Обновление БУС - рецепты Делаем горячий бэкап «боевого» проекта на БУС. Для максимально быстрого восстановления боевого проекта можно сделать бэкап через LVM-снепшот файлов и БД: 1) Лочим MySQL: «FLUSH TABLES WITH READ LOCK» 2) «Замораживаем» ФС (fsfreeze, xfs_freeze) 3) Делаем снепшот, в т.ч. рейдов с БД 4) «Размораживаем» ФС (fsfreeze, xfs_freeze) 5) Разлочиваем MySQL: «UNLOCK TABLES» Обновляемся на тестовом сервере, все тестируем и нагружаем (слайд «Обязательные шаги Deployment»). Обновляемся на «боевом», при минимальной посещаемости.

Обновление кода проекта - риски В скриптах создания объектов БУС используются ссылки на autoincrement-ids. Связи – ломаются. Объекты БУС не создаются на «бою», т.к. отсутствуют зависимости (нарушена синхронность систем). На «бою» кто-то внес изменения – может возникнуть конфликт Скрипт обновления не сообщает об успехе/ошибках Изменения в админках частично переносятся - вручную

Обновление кода проекта - рецепты Скрипты создания объектов БУС – ссылаются на символьные коды. Скрипты создания объектов БУС – ведут подробный лог работы и ошибок. Все скрипты обновлений – привязаны к релизам и хранятся в VCS (Version Control System). Менять код на «бою» - запрещено, логируем изменения файлов (inotify) Либо - все файлы «боевого» контента под контролем версий Используем diff-скрипты объектов БУС – для контроля синхронности.

Передача изменений Модели Нужно уметь переносить изменения данных с серверов разработки на тестовые, stage, production – серверы. Заскриптовать изменения инфоблоков, других объектов системы Diff-скрипты – сравниваем изменения настроек инфоблоков и др. Сохранять патчи в VCS Запускать скрипты создания объектов при переносе изменений К сожалению, пока не все объекты Битрикс можно переносить через API. Часть операций делается вручную. Ждем D7!

Функциональное тестирование Пишем интеграционные и функциональные тесты – запускается Максимально используем автоматику - Selenium Фоновое тестирование внутри компании Тестировщики иногда очень нужны Test Cases – доступны и их читают К сожалению, пока не все объекты Битрикс можно переносить через API. Часть операций делается вручную. Ждем D7!

Результат Ежедневно выполняются интеграционные, функциональные и модульные тесты – улучшается внутреннее качество Веб-система поддерживается в стабильном состоянии Можно достаточно часто выгружать изменения на боевые сервера Подход эффективно работает совместно с гибкими методологиями Клиент видит прогресс по проекту, отдачу Не срываются сроки на релизах – плавное снижение рисков

Спасибо за внимание! Вопросы? Александр