Continuous Integration - от простого к сложному

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

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

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

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

Обзор

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

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

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

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

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

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

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

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

Спасибо за внимание! Вопросы? Александр Сербул serbul@1c-bitrix.ru @AlexSerbul

Continuous Integration - от простого к сложному