Continuous Delivery in Enterprise / Agile Kitchen 2016
Transcript of Continuous Delivery in Enterprise / Agile Kitchen 2016
Эволюция продукта
3
2004
Monolith
Patсhes
2007
Monolith
«Dll-hell»
~20 systems
Build system↑
Loosely-coupling↑
Patсhsets
2010
SOA↑
Continuous integration↑
Service Registry
~35 systems
10+ teams
Severe customers
Branch and release policy
Severe products ↑
2014
SOA implemented
BPM implemented: WF + SR
Contract-build validation
Continuous integration
~50 systems + external
15+ teams
Several customers
Several products with
branch and release policy ↑ – старт активности
FORIS FORIS
FORIS
SCP
FORIS
SCP НКИП
Эволюция продукта
4
2015
FORIS Continuous Delivery↑
Autodeploy
Autotest ↑
~50 systems
15+ teams
+
SmBP
BMS
Balance Storage
SCP New Arch 1.5.1
2016
FORIS Continuous Delivery
Continuous Monitoring↑
Infrastructure as Code (Azure)↑
~50 systems + partner systems
15+ teams
SCP Continuous Delivery↑
SmBP Continuous Delivery↑
↑ – старт активности
FORIS
SCP НКИП BS SmBP
BMS
Процессы
5
TFS
Инсталляторы БЛ и БД каждой
системы
Microsoft и .NET
110 000 000 значимых строк кода
270 SOA-служб
в 50 системах
Надпроцесс – Waterfall
6
ANALYSE
DEV
Прием
ФТ
TEST
Прием
Регресс
Тираж
2 месяца
Около года
Каждая фаза –
отдельный отдел
У каждой системы есть закрепленная
команда разработки – «владелец системы»
7
Роли в команде разработки:
• Тимлид
• Разработчик
• Продуктовый архитектор
• Модульный тестировщик
Проблематика
8
Высокие ОРЗ (общерелизные затраты) —
регресс, стабилизация и стенды
Низкий ТТD релиза + невозможность держать руку
на пульсе и в любой момент выпустить систему на
промышленную среду
Системно, ситуация по мере роста ф-ла
только усложняется
Проблематика: длительность обратной связи
Релизная политика
Календарная длительность обратной связи – месяцы
Нет возможности интеграционно тестировать на фазе разработки
Увеличенная стоимость бага
Проблематика: пиковая нагрузка, блокеры
тестирования
Релизная политика
Пиковая нагрузка по багам НФ и регресса в конце релиза (за
фазой разработки), блокеры тестирования
Фаза
разработки Как сейчас
Как хотелось бы
Проблематика
Макроуровень: ОРЗ на интеграцию
11
БОльшая часть общерелизных затрат производственного цикла приходится на
• Подъем релиза на ТС и последующие установки
• Поддержку тестирования на внутреннем ТС
• Smoke на внутреннем ТС
• Dry-Run на ТС заказчика
Проблематика
Макроуровень: ОРЗ на тестирование регресса
12
Большая часть общерелизных затрат производственного цикла находится в области
• Sanity
• Регресс
Проблематика
Микроуровень: затраты на один баг
13
На один баг:
Testing (Test) — 1 час
Testing (Creation) — 15 мин сбор логов
Integration (Localization) — 15 мин изучения стенда и логов
50% Testing (Add Logs) — 15 мин досбор других логов
50% Integration (Localization) — 15 мин изучения стенда и логов
Dev Team 1 (Localization) — 15 мин изучение логов
30% Testing (Add Logs) — 15 мин сбор логов (если удалились, то ретест)
Dev Team 1 (Localization) — 15 мин изучение логов
30%
Dev Team 2 (Localization) — 15 мин изучение логов
Testing (Retest + Add Logs) — 1 час на ретест (уже точно удалились) + сбор логов
Dev Team 1 или 2 (Fix) — 2 часа на исправление
Testing (Retest)
Календарно до разработки баг идет примерно 1 день. 1-2 дня на досбор логов и исправление. 1
день проверка исправления.
Проблематика:
Разделение ресурсов на разные версии
14
Делаем несколько параллельных релизов, каждый со своей
стабилизацией
Мировой опыт
15
Эксперты — Мартин Фаулер и Ко
подтверждают проблему
У нас есть антишаблоны и что улучшать.
Целевое состояние процесса
17
Непрерывная интеграция,
автотестирование
и поставка – Continuous Delivery
Авторазвертывание
• Тестирование установки
Автотестирование
• Модульные, API и интеграционные тесты
Быстрый и автоматический сбор всех логов
Постоянный, ежедневный процесс
• Проверка установки релиза/пачки, контроль
стабильности, как можно более раннее
обнаружение проблем
Сдвиг обнаружения багов «влево»
19
Эф
фект
ивность
исправл
ения
Время после внесения
бага
Цель:
насколько возможно
перемещать
обнаружение бага на
более ранний этап
«Left shifting bugs»
20
Это основа
Без автоматизации –
к сожалению не работает
Интеграционный стенд разработки – DEV-stand
Схема работы
21
ТС DEV B
Новые версии систем (билды) A, B, C
Несколько раз в сутки автоматом ставим все новые успешные билды
систем.
А C
D E
Из чего состоит авторазвертывание
24
1. Скачивание новых версий систем из репозитария
2. Стоп служб
3. Запуск инсталляторов с параметрами молчаливой
установки
4. Старт служб
Могут быть дополнительные шаги:
• Удаление пользовательских сессий с БД
• Вызов утилит импорта метаданных
• и т.д.
Если что-то пошло не так, то есть специалист инфраструктуры,
который решает проблему (системно!) или заводит
функциональный баг
Мы получили интеграционный стенд на
фазе разработки
25
Релизная политика
Находим инсталляционный баги на фазе разработки
Получили возможность интеграционно тестировать задачи на
фазе разработки, модульщиками
Упрощайте
26
Мы развернули весь FORIS на одной виртуалке (270 служб),
вместо 12+ серверов типового тестового стенда
Позднее отказались от процесса «заказа версий билдов к
установке» – ставится всегда последняя версия
Фокусируйтесь на основном
27
Автодеплой только для ветки MAIN • Ветка MAIN содержит самые свежие изменения кода решения.
• Ветка MAIN является интеграционной – в неё сливаются исправления из всех предыдущих
релизов, и от неё же ответвляются все будущие релизы.
• Любая доработка проходит через MAIN.
• Тестируя ветку MAIN мы разом тестируем новые доработки из всех веток
MAIN (Latest version)
4.7.1-R1
5.0.3 Pack 2
5.0.3.1 Pack 1
4.7.1
5.0.4 Pack 05.0.3.1 Pack 0
Focus on
integration
5.0.4 Pack 1
ChangesChanges
Time
Changes
Улучшающие обратные связи
Примеры
29
1. Уменьшение ручных действий при
установке БД
2. Ускорение старта-стопа служб.
Автоконтроль достигнутого времени
3. Все изменения стенда только автоматом,
либо специалистом инфраструктуры
Схема работы
30
Стенд нестабилен = новые версии систем ломают регресс основных
бизнес-процессов –> время полезной работы стенда не велико
Как сделать стенд стабильным?
ТС DEV
Новые версии систем (билды) A, B, C
B
А C
D E
Конвейер качества
31
ТС DEV
Стабильный
Автоматизированная установка билда и прогон модульных автотестов.
ТС DEV
Барьер
А
B
C
ТС
модуля А
ТС
модуля С Автоматизированная установка очередного билда и прогон интеграционного smoke-тестсета + API-тестов модуля. Стенд ежедневно пересоздается из стабильного TC DEV.
Стабильный DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов.
А B C D
B
C Система B не имеет модульных автотестов
Новые версии систем (билды) A, B, C
Очередь билдов к проверке
К о н в е й е р б и л д о в , к о н в е й е р к а ч е с т в а
Конвейер качества
33
ТС DEV
Стабильный
Автоматизированная установка билда и прогон модульных автотестов.
ТС DEV
Барьер
А
B
C
ТС
модуля А
ТС
модуля С Автоматизированная установка очередного билда и прогон интеграционного smoke-тестсета + API-тестов модуля. Стенд ежедневно пересоздается из стабильного TC DEV.
Стабильный DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов.
А B C D
B
C Система B не имеет модульных автотестов
Новые версии систем (билды) A, B, C
Очередь билдов к проверке
К о н в е й е р б и л д о в , к о н в е й е р к а ч е с т в а
Пирамида тестов
34
GUI,
Integration
Tests
Module / API
Tests
Unit Tests
Manual
Tests
Правильное распределение
ресурсов на автоматизацию,
для максимальной отдачи
Интеграционные • Прогоняются на полностью собранной системе,
наиболее бизнес- и пользователь-
ориентированные
• Наиболее багоемкие, при этом дорогие и
труднолокализуемые
• Для FORIS с применением Central Logging
проблема локализации уменьшается
Модульные • Прогоняются на локальных стендах модулей
• На сборочных серверах и на машине
разработчика
• Часть работает на общей инфраструктуре DEV-
стенда
Конвейер качества
35
ТС DEV
Стабильный
Автоматизированная установка билда и прогон модульных автотестов.
ТС DEV
Барьер
А
B
C
ТС
модуля А
ТС
модуля С Автоматизированная установка очередного билда и прогон интеграционного smoke-тестсета + API-тестов модуля. Стенд ежедневно пересоздается из стабильного TC DEV.
Стабильный DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов.
А B C D
B
C Система B не имеет модульных автотестов
Новые версии систем (билды) A, B, C
Очередь билдов к проверке
Unit tests
Module / API tests
Integration (GUI+API) tests
Автотестирование
Критерии
36
Автоматизированное тестсет запускается без участия человека, автоматом, с заданной частотой
Повторяемое / воспроизводимое можно запускать произвольное кол-во раз без доп. затрат на подготовку.
Результат зависит только от кода системы
Автоинтерпретирование результатов если тест упал, при неизменности данных и теста, значит проблема в коде.
Простая локализация ошибки / бага после выполнения тестсета автоматов имеется достаточное для локализации
количество логов / скриншотов + отчет
37
Код системы, тест и эталонные
данные соответствуют друг другу и
изменяются согласованно.
Имеют одинаковые процессы ведения версий (аналогичный коду) и исправления
ошибок.
Код
системы
Тест Эталонные
данные
38
Команды сосредотачиваются на
разработке.
Кода и теста, а не инфраструктуры. Остальное —
установка на стенд,
восстановление эталонных данных,
прогон тестов,
генерирование отчета,
сбор логов —
полностью автоматизировано и гарантировано работает.
Каждая команда поставляет свои автотесты
39
Технология используется для
написания как API-модульных, так и
интеграционных тестов.
40
Ведем их как эталонные в БД на выделенном
стенде (на DEV-стенде)
На этих данных ежедневно прогоняются тесты, затем
данные восстанавливаются на момент «до старта
автотестов»
Процесс верификации данных и их актуализации
При внесения изменений в код, требующих также модификации теста:
1. Меняется код теста в ветке кода
2. Меняются данные в БД
3. Запускается тест (локально), добиваемся его выполнения
При падении теста при его выполнении (в рамках ежедневного
автотестирования):
1. Идет анализ причин падения
2. Если выявлена проблема в данных – они модифицируются на
стенде
Таким образом данные развиваются и поддерживаются в актуальном
состоянии, соответствуют коду и тестам, удовлетворяют критериям
Автотестирование
Эталонные данные и автоинтерпретация результата
41
Эталонные данные после прогона
автотестов восстанавливаются.
Так как тесты портят данные, важно после получения результата тестов вернуть стенд в
предыдущее состояние.
Это обеспечивает также однозначную интерпретируемость результата тестов.
Автотестирование
Эталонные данные
42
Концептуально делятся на две части
Метаданные (настройки) • Реиспользуются между несколькими тестами
• Меняются редко, ответственным за ведение эталонной модели данных
Пример: тарифные планы, услуги с параметрами, шаблон документа
Данные для конкретного теста • Принадлежат конкретному тесту, служат для изоляции тестов между
собой
• Меняются часто, вместе с тестом и кодом
Пример: абонент, симкарта
43
Собственные эталонные данные у
каждого теста. Изоляция.
Каждый тест использует только свои данные. Кроме общих метаданных.
Когда есть проблема с данными, мы однозначно знаем какие данные править.
Автотестирование
Итоговый процесс
44
Каждую ночь
1. Сохранение снепшота всего стенда, для возможности отката в случае
проблем установки или подъема
• Бизнес-логики (виртуалка)
• БД (виртуалка, либо дамп)
2. Сборка всех систем (включая тесты) по последним исходникам
3. Установка бизнес-логики всех систем на стенд
4. Установка БД всех систем на стенд
5. Сохранение снепшота БД, для восстановления данных после тестов
6. Подъем стенда
7. Выполнение тестов и сохранение всех результатов (логи, скрины)
8. Генерирование отчета
9. Откат БД на состояние до начала тестов – п.5
Важные моменты 1. Тесты каждый раз прогоняются на своих эталонных данных, эти данные
дорабатываются/развиваются на стенде (в рамках ведения эталона)
2. После получения результата от тестов, БД восстанавливается. Нужно чтобы ручное
тестирование смогло продолжить с утра свои активности на БД, с чистыми эталонными
данными, а также эталонные данные могли актуализироваться/исправляться.
На основе TFS Test Lab
45
ТС DEV
Запуск тестов автоматом (с помощью спец. билда),
каждую ночь. Длительность около 3 часов на 2000 тестов
Все результаты сохраняются в TFS (test results)
20 тестовых агентов
47
Вся инфраструктура
«под капотом»
Central Logging
Service Registry
«Context» settings
Задает стиль BDD
Содержит общее
Имеет удобный
VisualStudion add-in
Автотестирование
Разработали свой API Test Component — Husky
Отчет о результатах автотестов
СТАЛО – отчет полностью переосмыслен
53
Удобная верстка, правильная группировка и сортировка
Общие ошибки запуска выводятся в специальном разделе:
В теле каждого теста есть индикатор массовой проблемы
Отчет о результатах автотестов
ТОП ошибок
54
57
Отчет о результатах автотестов
Как оценить стабильность ветки на основе
отчета?
PASSED AT LEAST ONCE.
Означает - есть ли у нас области, в которых мы долго (дольше недели или 3 дней) не можем
успешно прогнать тесты.
«Убирает шумы» от нестабильности инфраструктуры и единичных выбросов.
Баланс тестов
60
GUI,
Integration
Tests
Module / API
Tests
Unit Tests
Manual
Tests
Какой баланс тестов у нас?
Достаточно много
интеграционных тестов, но
они дают нам быструю
локализацию за счет Central
Logging
Большинство API, а не GUI • Надежнее
• Быстрее
• Удобнее в поддержке
Сложность написания АТ
1. Подготовка тестовых данных – 40%
2. Написание теста – 20%
3. Отладка – 40%
1. Подготовка сложных данных может занимать по трудозатратам
дни, календарно – недели (из-за багов смежных ф-лов и т.д.)
2. Вопрос с отладкой теста, который в ходе своей работы изменяет
данные достаточно сложный. В дальнейшем мы придумали
отладку на Dev-стенде
Подтвердили концепции
Изоляция Нагенерировали абонентов по командам
Подтвердили и использовали концепцию «1 тест = 1 абонент»
Метаданные Приняли решение все метаданные заводить через одного
человека и никому больше не менять
Добавляем автотесты
ТС DEV
НEстабильный
Автоматизированная установка билда и прогон модульных автотестов.
ТС DEV
Барьер
ТС
модуля А
ТС
модуля С DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов.
А B C D
B
C Система B не имеет модульных автотестов
Новые версии систем (билды) A, B, C
Очередь билдов к проверке
А
B
C
Мы перешли к ежедневной
стабилизации релиза
64
Разработка — основной
ответственный за стабильность.
Версия не передается дальше, если не
проходит внутреннее качество.
До появления модульщиков была задача только написать код.
С модульщиками – проверить насколько возможно систему.
Сейчас цель – работоспособность всего нового кода и стабильность регресса. В том
числе и интеграционная.
65
Цель:
MAIN — это стабильная версия, всегда
готовая всегда к выпуску в продакшен.
Меняем подход к работе с MAIN
• не выкладывать код в ветку, пока он не будет целостно завершен (для этого можно держать
его локально, в шелве или тимворке)
• разбивать задачи так, чтобы скажем раз в день вы чекинили целостный кусок работы,
который за ночь подружится с другими кусками/командами
• при необходимости поломать внешнее АПИ, нужно будет сначала выставить новое, затем
убедиться что все потребители на него перешли, затем удалить старое (обычно в
следующем релизе)
• что-то еще
66
Сломанный регресс MAIN — это авария
в производстве, решается с нулевым
приоритетом.
Фокус всей компании на стабильности MAIN.
Отчеты MAIN на планерках производства, на еженедельных планерках производства и ИК.
Остановка производства, любых работ и починка аварии. Подобная критичность у всех
элементов конвейера билдов.
Вспомним проблематику
Релизная политика
Пиковая нагрузка по багам НФ и регресса в конце релиза (за
фазой разработки), блокеры тестирования
Фаза
разработки Как сейчас
Как хотелось бы
68
АФ DEV Пр. ФТ ТЕСТ Пр. регресс Тираж
Vision
D1
Пр. ФТ
Т1
Пр. регресс Тираж A2
D2
Т2
A3
D3
Т3
ТЕСТ
DEMO
A1
Спринты
«Agile-подход»
«Continuous Delivery»
«Canary Releases»
Целевая схема
Текущая схема
Производство 2.0
Continuous Delivery + Agile
CD экономит трудозатраты и сокращает календарь релизов.
На примере релиза 5.2:
o не пропустили баги, которые бы полностью заблокировали (не работает базовый
процесс из смоук-тестсета) тестирование больше 20 раз
Пример:
1. тестовый билд ОКАТа не менее 13 раз позволил оперативно обнаружить ошибки в отгруженном
функционале, баги в этом случае не заводили, и этим тоже сэкономили время
2. баги изменения построения корзины: отключали установку на стенд ФТ пока не стабилизировали
БП на стенде DEV
Заблокированное тестирование – это сдвиг окончания сроков тестирования как минимум на неделю**.
Из-за таких недель в итоге сдвигаются даты тиража.
o вместо 350 тестов внутреннего регресса откатили 128 тестов, вместо двух откатов
сделали один (из-за наличия автотестов)
Экономия времени команды тестирования не менее 420 часов ***
o сократили регрессионные проверки задачи функционального тестирования
Пример: задача 1059196, примерно на 40 часов ****
Итого CD в этой части сократил календарь 5.2 минимум на 1 неделю и сэкономили 460 чч
Сокращение затрат
Регресс
71
CD экономит время и сокращает календарь smoke и sanity
o Установка и развертывание стенда 5.2 заняли 2 дня вместо недели-двух
Smoke тестирование было пройдено за 3 дня вместо 2х недель
Экономия времени интеграции – 116 чч*
o Коэффициент допрохода в sanity был меньше обычно – 1,79 (за счет того, что релиз
поступил в тестирование с несколько раз пройденным частичным регрессом)
По данному коэффициенту можно судить о стабильности релиза (по информации от тестирования:
«обычно 2 - очень хорошо, максимально бывало 4»):
2-3 - релиз стабилен, от 3 и выше - релиз нестабилен.
Т.к. мы выпускали релиз из ветки MAIN, коэффициент без автотестов был бы не меньше 3.
То есть мы бы должны были пройти еще 230 тестов.
Это бы заняло у нашей команды 9 дней.
Команда с частичной занятостью имела емкость 45,44чч в день
Итого экономия времени составила 409 часов **
В итоге 5.2 стал готов к регрессионном тестированию на 1 месяц раньше и мы сэкономили
на smoke и sanity 525 чч
Сокращение затрат
Smoke и sanity тестирование
72
Автотесты сокращают затраты на выпуск релиза за счет сокращения затрат на модульное тестирование
o Не нужно проводить трудоемких разборов доработок на предмет «на что могло повлиять»
o В модульном тестировании можно не проводить трудоемких тестов для проверки регресса (особенно актуально по большим БП: расторжение, смена владельца, перенос ПО, смены ТП, ДУУ)
o На этапе модульного тестирования можно сократить объем регрессионных тестов (особенно актуально по большим БП: расторжение, смена владельца, перенос ПО, смена ТП, ДУУ)
o Есть возможность сравнивать логи прохождения теста до исправлений и после, что сокращает затраты на локализацию бага
• Это ускоряет локализацию, т.к. легче найти, что было изменено
Основная часть автотестов разрабатывалась в 5.2, поэтому экономия времени сможем посчитать в очередных релизах.
При этом даже сейчас в 5.2, на примере команды OCF видим, что покрытие автотестами нам поможет в 5.2 не потратить 40 чч на регресс по задаче 1083900.
Сокращение затрат
Модульное тестирование
73
Исправлять баги, найденные автотестами, дешевле
В среднем стоимость исправления бага ниже в 2 раза
2чч vs 4чч
На примере команды ОМ:
o Около 50% багов находится и исправляется с помощью СD
o Для 50% багов мы не тратим время на обнаружение, нахождение логов, проверку корректности исправления
На нахождение 101 бага потратили ~35 часов (списали на таски по разбору багов), на исправление 52 бага потратили ~100 часов (в среднем на такие баги <2 часов). Всего на цикл из 101 бага потратили <150 часов.
В среднем разработка на баг без исправлений тратит 2 часа, на баг с исправлениями тратит 4-6 часов. Итого в
среднем на 101 баг (из них 52 с исправлениями) потратили бы >300. Экономия только в команде ОМ составила больше 150 часов
Всего автотесты в релизе 5.2 (на 15.12.2015) нашли 20% багов с исправлениями (200 только по ТФС) и сэкономили до 800 часов:
команд разработки (400*), интеграции (200**) и тестирования (200***),
а также сократили календарь, т.к. многие были найдены до этапа ФТ и регресса и не мешали их прохождению
Сокращение затрат
Стоимость бага
74
Исправлять баги, найденные автотестами, дешевле
CD упрощает и облегчает процесс – не все
баги заводятся в ТФС (особенно с модульных
тестовых стендов), а исправляются сразу.
На примере команды Оcat:
за декабрь 2015 найдено 19 багов, которые правились без заведения в ТФС
Сокращение затрат
Стоимость бага
75
CD экономит время интеграции с помощью автоустановок
o Автоустановки на стенд
o Информация об установке исправления на стенд теперь пишется в баг, не надо искать по TFS
деплойменты
o Сократили количество ручных скриптов
Экономия времени интеграции составила около 100 чч * (в релизе 5.2)
+ Упростили производственный процесс на фазе разработки: отказались вообще от
процесса заведения в ТФС воркайтемов ship, deployment.
Соответственно это привело к экономии времени разработки (на создание шипа), тестирования на
анализ шипов и заведение деплойментов.
Сокращение затрат
Интеграция (автоустановки)
76
Аккумулируя предыдущие слайды – только в релизе
5.2 экономия времени составила 1900чч и больше
месяца в производственном календаре.
За счет того, что:
o Меньше багов на начальном этапе стабилизации, релиз поступает в тестирование с
частично проверенным регрессом
o Меньше откатов и регрессионных проверок
o В 3 раза дешевле локализация и исправление багов (стоимость бага сокращается с 6чч
до 2 чч): раньше 4чч разработки + 1ч тестирования + 1ч интеграции, теперь только 2чч
разработки
Сокращение затрат
Общий итог
77
Автотесты улучшают качество выпускаемых доработок
o Можем выбирать более качественные решения, т.к. не боимся влияния на регресс, его
проверят автотесты
o В процессе создания тестов производим рефакторинг легаси-кода
o Пока мы писали новые тесты, мы находили и исправляли баги в коде**
o На примере команды OCF хрупкость модуля* снизилась в 2 раза относительно прошлых
релизов и составила 5%
o Коэффициент допрохода тестов в 5.2 равен примерно 2. По данному коэффициенту можно судить о стабильности релиза (по информации от тестирования: "Обычно 1 к 2 - очень хорошо, максимально бывало 1 к 4"):
2-3 - релиз стабилен,
от 3 и выше - релиз нестабилен.
То есть релиз, который мы выпустили из ветки MAIN, оказался стабильным.
Качество
78
o Составлены стратегии автотестирования для каждого модуля
o Процесс написание автотестов встроен в процесс разработки (новый функционал всегда идет
с АТ, также покрываем тестами сложные баги)
o Во многих командах существенно поднята компетенция по написанию автотестов
o Всегда актуальная документация в виде тестов
Баги более равномерно размазываются по итерации
разработки и стабилизации и не заваливают пиково в конце как
раньше. Массовых проблем в принципе нет, находятся только
точечные баги в конкретных кейсах.
Процессные достижения
79
o Production-quality tests. Ручным тестированием как правило занимались
только модульное тестирование. Автотесты пишет вся команда
o Мотивация модульных тестировщиков. Существенно веселее, чем ручное
тестирование. «Мотивитует» к изучению основ программирования
o Упрощен ввод новых разработчиков в команду. Можно дать
задачу покрыть процесс тестами – естественным образом придется разобраться в
технологиях, структуре проектов, составе модулей на ограниченном функционале, при
этом сразу охватив и поняв весь БП, начать от простых кейсов, постепенно переходя к
сложным (а не ковырять какой-то баг, не понимая, что и для чего исправляется)
o Команды расширили свои знания по другим системам, т.к. приходиться делать настройки и
подготовку данных для тестов
o Эффект накопления и улучшения данных на основе Dev-стенда. Все затраты по его настройке, ведения задач остаются и поддерживаются постоянно. Не
выбрасываются в конце каждого релиза или для конкретного проекта/Заказчика
Дополнительные преимущества
80
Подтверждение концепции.
Анализ простоев тестирования в 5.2 показал, что барьерный стенд исключит их
появление
Простой тестирования – это ситуация, когда вся команда тестирования не может проходить тесты (из-
за неработающих критичных БП, не поднимающихся служб).
На примере 5.2:
o 1083578 не запускается служба СМ
o 1080247 не открывалась форма ДУУ, не запрашивался баланс
o 1082355 не стартует служба FORIS.SPA.SA.HLR.NSN
o 1073962 ,1070756 не работает ДУУ
o 1061114 ошибка ДУУ
o и т.п.
Ни один из билдов не прошел бы барьерный стенд.
Барьерный стенд
81
Распределение багов регресса,
найденных на разных стадиях релиза: от 5.0.3.1 (1.5 года назад) к 5.3 (полгода назад)
Прогресс в одной картинке
82
Подтверждение концепции.
Анализ простоев тестирования в 5.2 показал, что барьерный стенд исключит их
появление
Простой тестирования – это ситуация, когда вся команда тестирования не может проходить тесты (из-
за неработающих критичных БП, не поднимающихся служб).
На примере 5.2:
o 1083578 не запускается служба СМ
o 1080247 не открывалась форма ДУУ, не запрашивался баланс
o 1082355 не стартует служба FORIS.SPA.SA.HLR.NSN
o 1073962 ,1070756 не работает ДУУ
o 1061114 ошибка ДУУ
o и т.п.
Ни один из билдов не прошел бы барьерный стенд.
83
Еще немного
про выращивание
86
Ежедневная работа
с агентами изменений, тимлидами
Стратегии автотестирования каждого модуля
Процесс написание автотестов встроен в процесс
разработки (новый функционал всегда идет с АТ, также
покрываем тестами сложные баги)
Поднимаем компетенции по написанию автотестов у
каждого участника команды (разработчики и
модульщики)
87
А может KPI?
Процент багов регресса, которые должны
находиться с помощью автотестов
технологии Continuous Delivery.
Например 70%.
Достроить конвейер качества
и перевести его в «облако». Нужна гибкость
90
ТС DEV
Стабильный
Автоматизированная установка билда и прогон модульных автотестов.
ТС DEV
Барьер
А
B
C
ТС
модуля А
ТС
модуля С Автоматизированная установка очередного билда и прогон интеграционного smoke-тестсета + API-тестов модуля. Стенд ежедневно пересоздается из стабильного TC DEV.
Стабильный DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов.
А B C D
B
C Система B не имеет модульных автотестов
Новые версии систем (билды) A, B, C
Очередь билдов к проверке
К о н в е й е р б и л д о в , к о н в е й е р к а ч е с т в а
91
Vision
D1
Пр. ФТ
Т1
Пр. регресс Тираж A2
D2
Т2
A3
D3
Т3
ТЕСТ
DEMO
A1
Спринты
«Agile-подход»
«Continuous Delivery»
Умощнить базу регресс-автотестов
и перейти на применение Agile-практик
91
Распространить Continuous Delivery на все
продукты Компании и ИТ-ландшафта
92
FORIS
SCP НКИП BS SmBP
BMS
Выживает самый гибкий и быстрый
“Many industry watchers believe that DevOps
has been an essential component in
their meteoric growth.”
Из отчета New Relic – Navigating DevOps
94
Цель:
Continuous Delivery — в ДНК компании.
Спасибо!
Бирюков Павел
pavel.biryukov