Continuous Delivery in Enterprise / Agile Kitchen 2016

Выращивание

Continuous Delivery

в Enterprise

Бирюков Павел, 09.06.2016

[email protected]

2

Проблематика

Dev-стенд и автоустановка

Эволюция продукта

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 мин сбор логов (если удалились, то ретест)


30%


Testing (Retest + Add Logs) — 1 час на ретест (уже точно удалились) + сбор логов

Dev Team 1 или 2 (Fix) — 2 часа на исправление

Testing (Retest)

Календарно до разработки баг идет примерно 1 день. 1-2 дня на досбор логов и исправление. 1

день проверка исправления.

Проблематика:

Разделение ресурсов на разные версии

14

Делаем несколько параллельных релизов, каждый со своей

стабилизацией

Мировой опыт

15

Эксперты — Мартин Фаулер и Ко

подтверждают проблему

У нас есть антишаблоны и что улучшать.

16

Представьте себе

Целевое состояние процесса

17

Непрерывная интеграция,

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

и поставка – Continuous Delivery

Авторазвертывание

• Тестирование установки

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

• Модульные, API и интеграционные тесты

Быстрый и автоматический сбор всех логов

Постоянный, ежедневный процесс

• Проверка установки релиза/пачки, контроль

стабильности, как можно более раннее

обнаружение проблем

18

Непрерывная стабилизация.

Максимальная автоматизация.

Основной концепт.

Сдвиг обнаружения багов «влево»

19

Эф

фект

ивность

исправл

ения

Время после внесения

бага

Цель:

насколько возможно

перемещать

обнаружение бага на

более ранний этап

«Left shifting bugs»

20

Это основа

Без автоматизации –

к сожалению не работает

Интеграционный стенд разработки – DEV-stand

Схема работы

21

ТС DEV B

Новые версии систем (билды) A, B, C

Несколько раз в сутки автоматом ставим все новые успешные билды

систем.

А C

D E

Автоустановка

22

Автоустановка

23

Из чего состоит авторазвертывание

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

Постоянное улучшение авторазвертывания

28

Запуск

улучшающих

обратных

связей

Улучшающие обратные связи

Примеры

29

1. Уменьшение ручных действий при

установке БД

2. Ускорение старта-стопа служб.

Автоконтроль достигнутого времени

3. Все изменения стенда только автоматом,

либо специалистом инфраструктуры

Схема работы

30

Стенд нестабилен = новые версии систем ломают регресс основных

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

Как сделать стенд стабильным?

ТС DEV


B

А C

D E

Конвейер качества

31

ТС DEV

Стабильный

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

ТС DEV

Барьер

А

B

C

ТС

модуля А

ТС

модуля С Автоматизированная установка очередного билда и прогон интеграционного smoke-тестсета + API-тестов модуля. Стенд ежедневно пересоздается из стабильного TC DEV.

Стабильный DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов.

А B C D

B

C Система B не имеет модульных автотестов


Очередь билдов к проверке

К о н в е й е р б и л д о в , к о н в е й е р к а ч е с т в а

32



33

ТС DEV



ТС DEV

Барьер

А

B

C

ТС

модуля А

ТС



А B C D

B





Пирамида тестов

34

GUI,

Integration

Tests

Module / API

Tests

Unit Tests

Manual

Tests

Правильное распределение

ресурсов на автоматизацию,

для максимальной отдачи

Интеграционные • Прогоняются на полностью собранной системе,

наиболее бизнес- и пользователь-

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

• Наиболее багоемкие, при этом дорогие и

труднолокализуемые

• Для FORIS с применением Central Logging

проблема локализации уменьшается

Модульные • Прогоняются на локальных стендах модулей

• На сборочных серверах и на машине

разработчика

• Часть работает на общей инфраструктуре DEV-

стенда


35

ТС DEV



ТС DEV

Барьер

А

B

C

ТС

модуля А

ТС



А B C D

B




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


Интеграция с Central Logging

48

Отчет о результатах автотестов

Одна из первых версий

Постоянное улучшение отчета АТ

50

Запуск

улучшающих

обратных

связей


Плюс привязанные баги и детали ошибок из Central Logging

52


Дальше больше – отчет полностью переосмыслен


СТАЛО – отчет полностью переосмыслен

53

Удобная верстка, правильная группировка и сортировка

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

В теле каждого теста есть индикатор массовой проблемы


ТОП ошибок

54

55


Детализация результатов тестов по бизнес-процессам

56

Процесс разбора отчета

57


Как оценить стабильность ветки на основе

отчета?

PASSED AT LEAST ONCE.

Означает - есть ли у нас области, в которых мы долго (дольше недели или 3 дней) не можем

успешно прогнать тесты.

«Убирает шумы» от нестабильности инфраструктуры и единичных выбросов.

58


Метрика стабильности PASSED AT LEAST ONCE

Новый отчет

сокращает

время

анализа

с 2 часов

до 30 минут

Sexy look

Баланс тестов

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




А

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

69

Результаты

Развитие

Сокращение затрат

Регресс

70

Немного цифр

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

Еще немного

про выращивание

84

Команда развития,

постоянное переосмысление и движение вперед

85

Тиражирование концепций, изменение парадигм,

внутренние семинары, вовлечение

86

Ежедневная работа

с агентами изменений, тимлидами

Стратегии автотестирования каждого модуля

Процесс написание автотестов встроен в процесс

разработки (новый функционал всегда идет с АТ, также

покрываем тестами сложные баги)

Поднимаем компетенции по написанию автотестов у

каждого участника команды (разработчики и

модульщики)

87

А может KPI?

Процент багов регресса, которые должны

находиться с помощью автотестов

технологии Continuous Delivery.

Например 70%.

88

Постоянное улучшение,

правильно выбранные рычаги и обратные связи

89

Развитие

Развитие

Достроить конвейер качества

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

90

ТС DEV



ТС DEV

Барьер

А

B

C

ТС

модуля А

ТС



А B C D

B





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 — в ДНК компании.

Спасибо!

Бирюков Павел

[email protected]

pavel.biryukov

Continuous Delivery in Enterprise / Agile Kitchen 2016

Software