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

для этой версии?
Когда тестировать?
Какая сборка стабильная?
… кто здесь?!…

А если сотни подсистем?
А если тысячи тестов?
Как этим управлять?

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

будет пользоваться;
с чем он уже работает;
какую часть можно улучшить.

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

платформы
Ресурсы
Отчеты

«ВЗЯТЬ»?
Только последний?
Где-то конкретно указанный?
Стабильную сборку?

действия
совершаются не просто так,
а преследуют некоторую цель, назовем это все Целью,
которая либо достигается, либо используются ее результаты.

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

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

и красивая схема. При наличии бинокля ее можно будет разглядеть. Или можно порисовать самостоятельно вместо перекура….

Цели либо выполняются, либо доставляются ее результаты.
Если одновременно есть и выполнение, и использование, то создаются связи.
Как действовать, если цель не выполнилась, и какие результаты какого именно выполнения надо использовать?

то свяжем все одинаковые цели между собой, и будем использовать именно их результаты.
Иначе будем использовать на выбор: самые достоверные результаты, последние, заданные вручную.

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

Опционально можно сделать и так:
При запуске теста выбирается дистрибутив из списка успешных
Если стадия разработки – берется последний, если в тестировании – переданный на тестирование.

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

Ресурс – это БД, общие файлы, данные, схемы, сервера и т.д.
Цель требует ресурсы для запуска, в Exclusive или Shared режиме.
Каждый ресурс имеет номинальную мощность, а цель – требуемую.
Цель может создать ресурс после своего выполнения
Группировка ресурсов по серверам или БД

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

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

При активации ресурса производится поднятие БД из снапшота М

При активации ресурса производится заполнение БД тестовыми данными набора К

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

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

Интерфейс!

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

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

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

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

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

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



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

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

дефектах.
Исходные требования к подсистеме к моменту начала разработки превращаются в дефекты типа «пожелание по доработке»
Разработчик, создавая заявку на сборку, ставит галочки против открытых дефектов. Эта информация присутствует в отчете о сборке.
Если тест завершается с ошибкой, по его «результатам» создаются дефекты. Если дефект с таким именем уже есть и якобы исправлен – он открывается заново.
Если тест успешен, дефект закрывается.
По окончании тестирования - отчет с разницей дефектов в начале и в конце тестирования.

и куда-то положить. Положим его в специальный каталог рядом с подсистемой.
Не надо думать о том, где взять дистрибутивы – система сама положит их рядом и распакует, если необходимо.
Далее, надо описать тест как кирпичик. Указать исходные файлы теста, команду, и ожидаемые результаты. Указать тип теста.
Предыдущий пункт может сделать робот, который ходит по файловой системе.
Если тест требует ресурсов, например, выделенный БД, или подготовленной среды переменных окружения, это тоже надо заполнить.
Не нужно описывать то, когда будут запущены тесты, и вообще об этом думать. Достаточно указать, что он есть.

данной версии подсистемы. Они все будут запущены единообразно.
Если нужна более сложная последовательность, необходимо описать ее, к примеру, так:
для подсистем А и Б есть тесты:
функциональные Func-A1, Func-AB, Func-B1
нагрузочные Load-A1, Load-B1

подробнее

Но это только теория. На практике, у нас еще есть:
Регулярное тестирование – кодировки файлов, контроль русских символов, контроль правописания…
Выполнение задач по событиям (изменения статусов дефектов, наступление пятницы 13…)
Автоматическая чистка процессов на серверах
Управление нагрузкой
Средства формирования и рассылки отчетов

«экземпляров», каждый из которых имеет некоторую «удельную мощность», и может быть «привязан» к серверу.
Захват полной группы – одновременный захват всего списка
Групповой захват – группа должна быть одинакова
Одновременный захват ресурсов для группы целей




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

должна быть выполнена на некоторой платформе.

вытащить все исходные коды, находящиеся в разработке, и проверить:
Орфографию
Web-части:
проверить кодировку
соответствие правилам разработки -
SQL :
контроль русских символов
список пакетов pl/sql, их состав и взаимные вызовы
Исходный код:
изменение SLOC
матерный словарь

пройти по своей БД и вызвать функцию запуска, то:









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

Если не отключен режим автосборки – то собирать каждую ночь и выполнять все тесты
Для больших тестов – запускать, к примеру, по пятницам в 22:00
Для контроля оперативных данных – формирование отчетов каждые 2 часа

– логин из пула пользователей.

Активация – удаляются все процессы этого пользователя на сервере.
Выполняется произвольный пользовательский код
Деактивация – так же удаляются все процессы
Unix – kill, Windows – WinSSHd
Дополнительно – робот удаления процессов старше 7 дней и defunc-процессов

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

нам index.html как результат своей работы
Выполнение – по заказу или по расписанию