ОПЫТ СОЗДАНИЯ СИСТЕМЫ УПРАВЛЕНИЯ

СБОРКОЙ И ТЕСТИРОВАНИЕМ

ОЛЕГ ЛАДЫГИН

OLADYGIN@GMAIL.COM

ЧАСТЬ 0 - ТЕОРЕТИЧЕСКАЯ

О ЧЕМ РЕЧЬ ВООБЩЕ?

Где взять дистрибутив?

Что реализовано?

Что делает этот тест?

Тест валиден для этой версии?

Когда тестировать?

Какая сборка стабильная?

… кто здесь?!…

А если сотни подсистем?

А если тысячи тестов?

Как этим управлять?

Модель «Организационная жаба»

СНАЧАЛА НАДО ПОДУМАТЬ

Прежде чем что-то разработать, надо определить:

кто этим будет пользоваться;

с чем он уже работает;

какую часть можно улучшить.

В итоге – надо подумать.

АРТЕФАКТЫ

Дистрибутив

Исходный код

Сборка

Тест

Стабильная сборка

Тип теста

Дефекты

Bug-tracking

Система управления версиями (CVS)

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

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

…

Отгрузка

Сервера и платформы

Ресурсы

Отчеты

АВТОМАТИЗИРУЕМ? НАДО ФОРМАЛЬНО ОПИСАТЬ.

Взять исходные файлы

Закинуть на сервера

Выполнить команды

компиляцииСобрать в кучу

Обернуть инсталлятором в

пакетик, надписать, что исправлено и

реализовано, всем рассказать.

Как выглядит сборка

Как выглядит тестирование

Взять файлы теста Взять дистрибутив Подготовить тестовую среду Что-то запустить

Получить какие-то результаты, где-то сохранить, всем

рассказать, закрыть/создать

баги.

Дистрибутив

Собрать серверную часть

Сборка на платформе А Взять исходники

Сборка на платформе Б Взять исходники

Собрать исходники серверной части

Собрать клиентскую часть

Собрать исходники

клиентской части

Как еще выглядит сборка

Как еще выглядит тестирование

ВАРИАНТ ОПИСАНИЯ - ДЕРЕВО

Набор тестов

Тест Т1 Подготовить среду

Взять дистрибутив

Тест Т2 Тест Т3 Подготовить среду

Взять дистрибутив

Что значит «ВЗЯТЬ»?1. Только последний?2. Где-то конкретно

указанный?3. Стабильную сборку?

Блоки сборки, теста, подготовки среды можно описать единообразно.

Так как все эти действия

совершаются не просто так,

а преследуют некоторую цель, назовем это все Целью,

которая либо достигается, либо используются ее результаты.

ЧТО ВНУТРИ ПРЯМОУГОЛЬНИЧКОВ?

Исходные файлы

Конечные файлы

Логи сборки/тестов

Результаты работы

Происходит выполнение какой-то команды

ЗАЧЕМ НУЖНА СТРУКТУРА?

Подсистема

Сборка

Debug

Дистрибутив А

До версии 15

После версии 15

Release

Дистрибутив Б

Все версии

Тест

Functional

Тест 1

Исключение версии 6

Для остальных

версий

Тест 2

После версии 12

Regression

Тест 3

Кроме версии 12

Load

Тест 4

После версии 2

Автоматический поиск и выбор необходимых методов и данных.

ОБЪЕДИНИМ ВСЕ В СЛОЖНУЮ СХЕМУ….Если совместить предыдущие слайды, получится очень большая и красивая схема. При наличии бинокля ее можно будет разглядеть. Или можно порисовать самостоятельно вместо перекура….

Цели либо выполняются, либо

доставляются ее результаты. Если одновременно есть и выполнение,

и использование, то создаются связи. Как действовать, если цель не

выполнилась, и какие результаты

какого именно выполнения надо

использовать?

ПРЕВРАТИМ ДЕРЕВО В ГРАФ

Если множество целей выполняются в едином пространстве – то

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

именно их результаты. Иначе будем использовать на выбор: самые достоверные

результаты, последние, заданные вручную.

Что получим в переводе «на пожрать»? При одиночном запуске теста берутся стабильные

дистрибутивы. При запуске теста и сборки тестируется только эта

сборка

Опционально можно сделать и так: При запуске теста выбирается дистрибутив из списка

успешных Если стадия разработки – берется последний, если в

тестировании – переданный на тестирование.

Набор дистрибутивов

Сервер

Платформа А

Исходники

Платформа Б

Исходники

Исходники сервера Клиент

Исходники клиента

СВЯЗИ - АВТОМАТИЧЕСКИЕ

Набор тестов

Тест Т1

Подготовить среду

Дистрибутив

Тест Т2

Тест Т3

Подготовить среду

Дистрибутив

Тест Т1 Подготовить среду

Взять дистрибути

в

Некоторое пространство 2

Все тесты типа Functional Взять дистрибутив

Пространство 3

Билд 3

Билд 2

Билд 1

УПРАВЛЕНИЕ РЕСУРСАМИ

Не хватает одной детали – управления последовательностью

запуска тестов и подготовкой среды их выполнения.

Ресурс – это БД, общие файлы, данные, схемы, сервера и т.д.

Цель требует ресурсы для запуска, в Exclusive или Shared режиме.

Каждый ресурс имеет номинальную мощность, а цель – требуемую.

Цель может создать ресурс после своего выполнения

Группировка ресурсов по серверам или БД

ПОДГОТОВКА – КАК РЕСУРС

Логика ресурсного планирования обеспечивает не только

последовательность и непротиворечивость работы, но и удобство.

Тест L1 Подготовить среду Тест F2 Подготовить

средуВзять

дистрибутив

Тест L1 требует БД монопольно для crush-теста, БД должна быть поднята из снапшота M

Тест F2 требует БД для unit-теста, на БД должны быть данные набора К

Тест L1 Тест F2 Взять дистрибутив

Ресурс: База из снапшота М

Ресурс: База с данными К

При активации ресурса

производится поднятие БД из

снапшота М

При активации ресурса

производится заполнение БД

тестовыми данными набора К

ИТОГ – ПРИДУМАЛИ ОПИСАНИЕДАЛЕЕ – ПРЕДСТАВИМ МОДЕЛЬ

Необходимо описать сборку дистрибутива

Необходимо задать структуру тестов

Можно задать последовательность тестов, если требуется

Тесты описываются любым членом команды и легко доступны

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

Интерфейс!

ТРЕБОВАНИЯ К ИНТЕРФЕЙСУ

ГОСТ 19.201-78* Единая система программной документации. Техническое задание. Требования к содержанию и оформлению 18.12.1978ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮНастоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.требования к информационной и программной совместимости:

United System for Program Documentation. Technical specification for development. Requirements to contents and form of presentation

2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть

Требования:

1. Все должно быть максимально просто.

2. Можно собрать дистрибутив и его протестировать

3. Можно выполнить все тесты или только часть

4. Должны учитываться «ресурсы» (базы, сервера…), используемые для тестирования, прозрачно и автоматически

5. Все должно быть очень быстро.

6. Все должно быть очень прозрачно. Кто, куда, когда, и сколько.

БЫСТРО НАПИШЕМ ВЕСЬ КОД

Внешние системы

HTTP

SOAP

SOAP/SQL

SQL

SSH

FTP

MVFS

Интерфейс

Ядро и прочее

ВКЛЮЧАЕМ, ВСЕ РАБОТАЕТ

Представим, что ядро запущено, интерфейс не тормозит, задачи сборки/тестирования выполняются. И при этом нет ни одной проблемы в инфраструктуре. Как все это выглядит?

Разработчики – указывают в билдах, что именно реализовано или исправлено. Они же видят тесты и результаты.

А тестировщики?

Как это выглядит для них?

ТЕСТИРОВАНИЕ КАК РАБОТА Получение билда

Ожидать письма от разработчика, где есть ссылка на дистрибутив, список реализованной функциональности, результаты пройденных тестов. Или найти это все через веб.

Выполнение тестирования

Нажать кнопку «выполнить все» или выбрать, что же именно выполнить.

Оповещение разработчика

В вебе найти кнопку «завершить тестирование билда» – формируется отчет с созданными или закрытыми дефектами.

Написание тестов

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

Отчет о проделанной работе

Составляется автоматически – кто и что обнаружил, какие тесты написал.

КАК ЭТО РАБОТАЕТ, П. 1

Оповещение о разработанной функциональности, открытых и закрытых дефектах.

1. Исходные требования к подсистеме к моменту начала разработки превращаются в дефекты типа «пожелание по доработке»

2. Разработчик, создавая заявку на сборку, ставит галочки против открытых дефектов. Эта информация присутствует в отчете о сборке.

3. Если тест завершается с ошибкой, по его «результатам» создаются дефекты. Если дефект с таким именем уже есть и якобы исправлен – он открывается заново.

4. Если тест успешен, дефект закрывается.

5. По окончании тестирования - отчет с разницей дефектов в начале и в конце тестирования.

КАК ЭТО РАБОТАЕТ, П. 2

Создание тестов

1. В первую очередь, тест надо написать и куда-то положить. Положим его в специальный каталог рядом с подсистемой.

2. Не надо думать о том, где взять дистрибутивы – система сама положит их рядом и распакует, если необходимо.

3. Далее, надо описать тест как кирпичик. Указать исходные файлы теста, команду, и ожидаемые результаты. Указать тип теста.

4. Предыдущий пункт может сделать робот, который ходит по файловой системе.

5. Если тест требует ресурсов, например, выделенный БД, или подготовленной среды переменных окружения, это тоже надо заполнить.

6. Не нужно описывать то, когда будут запущены тесты, и вообще об этом думать. Достаточно указать, что он есть.

КАК ЭТО РАБОТАЕТ, П. 3

Выполнение тестирования

1. Система знает, какие тесты существуют для данной версии подсистемы. Они все будут запущены единообразно.

2. Если нужна более сложная последовательность, необходимо описать ее, к примеру, так:

• для подсистем А и Б есть тесты:• функциональные Func-A1, Func-AB, Func-B1 • нагрузочные Load-A1, Load-B1

Тест Васи

Load-A1 Func-ABДистрибутив A

Дистрибутив B

Load-B1Func-A1 Дистрибутив A

Func-B1 Дистрибутив B

ЧАСТЬ 0 - ТЕОРЕТИЧЕСКАЯ

ЧАСТЬ 1 - ПРАКТИЧЕСКАЯ

ЧТО ЖЕ НА ПРАКТИКЕ?

Подробнее о ядре

Ресурсы – подробнее

Выполнение задач - подробнее

Но это только теория. На практике, у нас еще есть:

Регулярное тестирование – кодировки файлов, контроль русских символов, контроль правописания…

Выполнение задач по событиям (изменения статусов дефектов, наступление пятницы 13…)

Автоматическая чистка процессов на серверах

Управление нагрузкой

Средства формирования и рассылки отчетов

ПОДРОБНЕЕ О РЕСУРСАХ

Ресурс - это именованная запись, имеющая один и более «экземпляров», каждый из которых имеет некоторую «удельную мощность», и может быть «привязан» к серверу.

Захват полной группы – одновременный захват всего списка

Групповой захват – группа должна быть одинакова Одновременный захват ресурсов для группы целей

Разный тип ресурса – разная процедура активации Каждый ресурс имеет набор параметров и группу Пользовательские и системные ресурсы Конструкторы и деструкторы ресурсов

Захват Активация Работа Освобождение

Деактивация

ПОДРОБНЕЕ О ЗАДАЧАХ

Задача – запись о том, что некоторая версия цели должна быть выполнена на некоторой платформе.

За

хват

рес

урсо

в Введена• Задача находится в

очереди

Захвачена• Ресурсы задачи

захвачены

Активация• Подготавливаются

ресурсы задачи

Активирована• Ресурсы задачи

подготовлены

Вы

пол

нени

е Выполняется• Задача выполняется

В ожидании• Задача ожидает ресурсы

Возобновлена• Задача возобновляет

выполнение после ожидания

Доставляется• Задача доставляет

результаты работы

Завершается• Задача подготавливается

к завершению

Осв

обож

де

ние

ре

сур

сов Деактивация

• Освобождаются ресурсы задачи

Деактивирована• Ресурсы задачи

освобождены

Завершена• Задача завершена

РЕГУЛЯРНОЕ ТЕСТИРОВАНИЕ

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

Орфографию Web-части:

проверить кодировку соответствие правилам разработки -

SQL : контроль русских символов список пакетов pl/sql, их состав и взаимные вызовы

Исходный код: изменение SLOC матерный словарь

ВЫПОЛНЕНИЕ ЗАДАЧ ПО СОБЫТИЯМ

Если для запуска любого теста или сборки достаточно пройти по своей БД и вызвать функцию запуска, то:

Дополнительно – внешний конвейер событий. Что туда положила внешняя система – будет исполнено. Это механизм scheduler-а на всей инфраструктуре. Или просто мега-триггер на какие-либо изменения.

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

Для больших тестов – запускать, к примеру, по пятницам в 22:00

Для контроля оперативных данных – формирование отчетов каждые 2 часа

АВТОМАТИЧЕСКАЯ ЧИСТКА ПРОЦЕССОВ

Задачи выполняются на серверах через SSH. Есть системный ресурс – логин из пула пользователей.

Активация – удаляются все процессы этого пользователя на сервере.

Выполняется произвольный пользовательский код

Деактивация – так же удаляются все процессы

Unix – kill, Windows – WinSSHd Дополнительно – робот удаления

процессов старше 7 дней и defunc-процессов

УПРАВЛЕНИЕ НАГРУЗКОЙ, ВЫБОР СЕРВЕРА

Управление нагрузкой – выбор сервера из нескольких доступных

Эксклюзивный захват сервера Активация сервера – установка набора переменных окружения

Платформа А

SERVER-A1 Текущая нагрузка 2/5

SERVER-A2 Текущая нагрузка 1/2

Платформа B

SERVER-B2 Текущая нагрузка 1/6

SERVER-B2 Нагрузка 1/6 монопольно

Платформа USER

SERVER-A1 Другие переменные окружения

SERVER-B2 Другие переменные окружения

ФОРМИРОВАНИЕ И РАССЫЛКА ОТЧЕТОВ

Отчет – лишь цель определенного типа Пусть она возвратит нам index.html как результат своей работы Выполнение – по заказу или по расписанию

ЧАСТЬ 0 – ТЕОРЕТИЧЕСКАЯ

ЧАСТЬ 1 – ПРАКТИЧЕСКАЯ

СПАСИБО

ОЛЕГ ЛАДЫГИН

OLADYGIN@GMAIL.COM