от простого к Continuous Integration - сложному Александр Сербул

Continuous Integration - от простого к
сложному
Александр Сербул
Руководитель направления контроля качества интеграции и внедрений
@AlexSerbul
Зачем?
Практика XP, но можно использовать отдельно
Для средних и крупных проектов
Возможность делать частые релизы
Снижаем риски срыва сроков
Автоматизируем рутину
В результате – Клиент доволен
Обзор
Непрерывный процесс тестирования и сборки
Обзор
Автоматизируем все, что можно
Обзор
Система контроля версий
Используем систему контроля версий: git,
mercurial, svn, bazaar
Добавляем модули, компоненты, шаблоны
Ядро - можно не добавлять
Создаем ветки, систему аудита и политики
коммита
Вешаем обработчики событий – hooks
Комитим часто, лучше – раз в день
Система контроля версий
Разработчик 1
Разработчик 2
Разработчик 3
Ветка 1
Ветка 2
Ветка 3
Вед. разработчик
Изменения в ветки
DEV/TESTING
переносит опытный
разработчик
Ветка
DEV
Серверы разработки
Ветка
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. Обновление кода
и БД «боевого»
проекта
Репозиторий кода
(SVN, mercurial, git,
bazaar)
3. Обновление
кода и БД тест.
проекта
0-1. Резервное
копирование перед
обновлением
4. Модульное
тестирование
5. Функциональное
тестирование
6. Нагрузочное
тестирование
Нелепости с боевым «железом»
Использование самодельных серверов подешевле
Десктопные диски в серверах/рейдах
База данных – на диске без … рейда
Сложные типы рейдов, которые могут тормозить и трудно
восстанавливаются – 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