Continuous Delivery in Enterprise / Agile Kitchen 2016
- 1. Выращивание Continuous Delivery в Enterprise Бирюков Павел, 09.06.2016 pbiryukov@gmail.com
- 3. Эволюция продукта 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. Эволюция продукта 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 НКИПBSSmBP BMS
- 5. Процессы 5 TFS Инсталляторы БЛ и БД каждой системы Microsoft и .NET 110 000 000 значимых строк кода 270 SOA-служб в 50 системах
- 6. Надпроцесс – Waterfall 6 ANALYSE DEV Прием ФТ TEST Прием Регресс Тираж 2 месяца Около года Каждая фаза – отдельный отдел
- 7. У каждой системы есть закрепленная команда разработки – «владелец системы» 7 Роли в команде разработки: • Тимлид • Разработчик • Продуктовый архитектор • Модульный тестировщик
- 8. Проблематика 8 Высокие ОРЗ (общерелизные затраты) — регресс, стабилизация и стенды Низкий ТТD релиза + невозможность держать руку на пульсе и в любой момент выпустить систему на промышленную среду Системно, ситуация по мере роста ф-ла только усложняется
- 9. Проблематика: длительность обратной связи Релизная политика Календарная длительность обратной связи – месяцы Нет возможности интеграционно тестировать на фазе разработки Увеличенная стоимость бага
- 10. Проблематика: пиковая нагрузка, блокеры тестирования Релизная политика Пиковая нагрузка по багам НФ и регресса в конце релиза (за фазой разработки), блокеры тестирования Фаза разработки Как сейчас Как хотелось бы
- 11. Проблематика Макроуровень: ОРЗ на интеграцию 11 БОльшая часть общерелизных затрат производственного цикла приходится на • Подъем релиза на ТС и последующие установки • Поддержку тестирования на внутреннем ТС • Smoke на внутреннем ТС • Dry-Run на ТС заказчика
- 12. Проблематика Макроуровень: ОРЗ на тестирование регресса 12 Большая часть общерелизных затрат производственного цикла находится в области • Sanity • Регресс
- 13. Проблематика Микроуровень: затраты на один баг 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. Проблематика: Разделение ресурсов на разные версии 14 Делаем несколько параллельных релизов, каждый со своей стабилизацией
- 15. Мировой опыт 15 Эксперты — Мартин Фаулер и Ко подтверждают проблему У нас есть антишаблоны и что улучшать.
- 17. Целевое состояние процесса 17 Непрерывная интеграция, автотестирование и поставка – Continuous Delivery Авторазвертывание • Тестирование установки Автотестирование • Модульные, API и интеграционные тесты Быстрый и автоматический сбор всех логов Постоянный, ежедневный процесс • Проверка установки релиза/пачки, контроль стабильности, как можно более раннее обнаружение проблем
- 19. Сдвиг обнаружения багов «влево» 19 Эффективностьисправления Время после внесения бага Цель: насколько возможно перемещать обнаружение бага на более ранний этап «Left shifting bugs»
- 20. 20 Это основа Без автоматизации – к сожалению не работает Интеграционный стенд разработки – DEV-stand
- 21. Схема работы 21 ТС DEVB Новые версии систем (билды) A, B, C Несколько раз в сутки автоматом ставим все новые успешные билды систем. А C D E
- 22. Автоустановка 22
- 23. Автоустановка 23
- 24. Из чего состоит авторазвертывание 24 1. Скачивание новых версий систем из репозитария 2. Стоп служб 3. Запуск инсталляторов с параметрами молчаливой установки 4. Старт служб Могут быть дополнительные шаги: • Удаление пользовательских сессий с БД • Вызов утилит импорта метаданных • и т.д. Если что-то пошло не так, то есть специалист инфраструктуры, который решает проблему (системно!) или заводит функциональный баг
- 25. Мы получили интеграционный стенд на фазе разработки 25 Релизная политика Находим инсталляционный баги на фазе разработки Получили возможность интеграционно тестировать задачи на фазе разработки, модульщиками
- 26. Упрощайте 26 Мы развернули весь FORIS на одной виртуалке (270 служб), вместо 12+ серверов типового тестового стенда Позднее отказались от процесса «заказа версий билдов к установке» – ставится всегда последняя версия
- 27. Фокусируйтесь на основном 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 0 5.0.3.1 Pack 0 Focus on integration 5.0.4 Pack 1 ChangesChanges Time Changes
- 29. Улучшающие обратные связи Примеры 29 1. Уменьшение ручных действий при установке БД 2. Ускорение старта-стопа служб. Автоконтроль достигнутого времени 3. Все изменения стенда только автоматом, либо специалистом инфраструктуры
- 30. Схема работы 30 Стенд нестабилен = новые версии систем ломают регресс основных бизнес-процессов –> время полезной работы стенда не велико Как сделать стенд стабильным? ТС DEV Новые версии систем (билды) A, B, C B А C D E
- 31. Конвейер качества 31 ТС DEV Стабильный Автоматизированная установка билда и прогон модульных автотестов. ТС DEV Барьер А B C ТС модуля А ТС модуля С Автоматизированная установка очередного билда и прогон интеграционного smoke-тестсета + API-тестов модуля. Стенд ежедневно пересоздается из стабильного TC DEV. Стабильный DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов. А B C D B CСистема B не имеет модульных автотестов Новые версии систем (билды) A, B, C Очередь билдов к проверке К о н в е й е р б и л д о в , к о н в е й е р к а ч е с т в а
- 33. Конвейер качества 33 ТС DEV Стабильный Автоматизированная установка билда и прогон модульных автотестов. ТС DEV Барьер А B C ТС модуля А ТС модуля С Автоматизированная установка очередного билда и прогон интеграционного smoke-тестсета + API-тестов модуля. Стенд ежедневно пересоздается из стабильного TC DEV. Стабильный DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов. А B C D B CСистема B не имеет модульных автотестов Новые версии систем (билды) A, B, C Очередь билдов к проверке К о н в е й е р б и л д о в , к о н в е й е р к а ч е с т в а
- 34. Пирамида тестов 34 GUI, Integration Tests Module / API Tests Unit Tests Manual Tests Правильное распределение ресурсов на автоматизацию, для максимальной отдачи Интеграционные • Прогоняются на полностью собранной системе, наиболее бизнес- и пользователь- ориентированные • Наиболее багоемкие, при этом дорогие и труднолокализуемые • Для FORIS с применением Central Logging проблема локализации уменьшается Модульные • Прогоняются на локальных стендах модулей • На сборочных серверах и на машине разработчика • Часть работает на общей инфраструктуре DEV- стенда
- 35. Конвейер качества 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. Автотестирование Критерии 36 Автоматизированное тестсет запускается без участия человека, автоматом, с заданной частотой Повторяемое / воспроизводимое можно запускать произвольное кол-во раз без доп. затрат на подготовку. Результат зависит только от кода системы Автоинтерпретирование результатов если тест упал, при неизменности данных и теста, значит проблема в коде. Простая локализация ошибки / бага после выполнения тестсета автоматов имеется достаточное для локализации количество логов / скриншотов + отчет
- 37. 37 Код системы, тест и эталонные данные соответствуют друг другу и изменяются согласованно. Имеют одинаковые процессы ведения версий (аналогичный коду) и исправления ошибок. Код системы Тест Эталонные данные
- 38. 38 Команды сосредотачиваются на разработке. Кода и теста, а не инфраструктуры. Остальное — установка на стенд, восстановление эталонных данных, прогон тестов, генерирование отчета, сбор логов — полностью автоматизировано и гарантировано работает.
- 39. Каждая команда поставляет свои автотесты 39 Технология используется для написания как API-модульных, так и интеграционных тестов.
- 40. 40 Ведем их как эталонные в БД на выделенном стенде (на DEV-стенде) На этих данных ежедневно прогоняются тесты, затем данные восстанавливаются на момент «до старта автотестов» Процесс верификации данных и их актуализации При внесения изменений в код, требующих также модификации теста: 1. Меняется код теста в ветке кода 2. Меняются данные в БД 3. Запускается тест (локально), добиваемся его выполнения При падении теста при его выполнении (в рамках ежедневного автотестирования): 1. Идет анализ причин падения 2. Если выявлена проблема в данных – они модифицируются на стенде Таким образом данные развиваются и поддерживаются в актуальном состоянии, соответствуют коду и тестам, удовлетворяют критериям Автотестирование Эталонные данные и автоинтерпретация результата
- 41. 41 Эталонные данные после прогона автотестов восстанавливаются. Так как тесты портят данные, важно после получения результата тестов вернуть стенд в предыдущее состояние. Это обеспечивает также однозначную интерпретируемость результата тестов.
- 42. Автотестирование Эталонные данные 42 Концептуально делятся на две части Метаданные (настройки) • Реиспользуются между несколькими тестами • Меняются редко, ответственным за ведение эталонной модели данных Пример: тарифные планы, услуги с параметрами, шаблон документа Данные для конкретного теста • Принадлежат конкретному тесту, служат для изоляции тестов между собой • Меняются часто, вместе с тестом и кодом Пример: абонент, симкарта
- 43. 43 Собственные эталонные данные у каждого теста. Изоляция. Каждый тест использует только свои данные. Кроме общих метаданных. Когда есть проблема с данными, мы однозначно знаем какие данные править.
- 44. Автотестирование Итоговый процесс 44 Каждую ночь 1. Сохранение снепшота всего стенда, для возможности отката в случае проблем установки или подъема • Бизнес-логики (виртуалка) • БД (виртуалка, либо дамп) 2. Сборка всех систем (включая тесты) по последним исходникам 3. Установка бизнес-логики всех систем на стенд 4. Установка БД всех систем на стенд 5. Сохранение снепшота БД, для восстановления данных после тестов 6. Подъем стенда 7. Выполнение тестов и сохранение всех результатов (логи, скрины) 8. Генерирование отчета 9. Откат БД на состояние до начала тестов – п.5 Важные моменты 1. Тесты каждый раз прогоняются на своих эталонных данных, эти данные дорабатываются/развиваются на стенде (в рамках ведения эталона) 2. После получения результата от тестов, БД восстанавливается. Нужно чтобы ручное тестирование смогло продолжить с утра свои активности на БД, с чистыми эталонными данными, а также эталонные данные могли актуализироваться/исправляться.
- 45. На основе TFS Test Lab 45 ТС DEV Запуск тестов автоматом (с помощью спец. билда), каждую ночь. Длительность около 3 часов на 2000 тестов Все результаты сохраняются в TFS (test results) 20 тестовых агентов
- 46. 47 Вся инфраструктура «под капотом» Central Logging Service Registry «Context» settings Задает стиль BDD Содержит общее Имеет удобный VisualStudion add-in Автотестирование Разработали свой API Test Component — Husky
- 47. Автотестирование Интеграция с Central Logging 48
- 48. Отчет о результатах автотестов Одна из первых версий
- 49. Постоянное улучшение отчета АТ 50 Запуск улучшающих обратных связей
- 50. Отчет о результатах автотестов Плюс привязанные баги и детали ошибок из Central Logging
- 51. 52 Отчет о результатах автотестов Дальше больше – отчет полностью переосмыслен
- 52. Отчет о результатах автотестов СТАЛО – отчет полностью переосмыслен 53 Удобная верстка, правильная группировка и сортировка
- 53. Общие ошибки запуска выводятся в специальном разделе: В теле каждого теста есть индикатор массовой проблемы Отчет о результатах автотестов ТОП ошибок 54
- 54. 55 Отчет о результатах автотестов Детализация результатов тестов по бизнес-процессам
- 56. 57 Отчет о результатах автотестов Как оценить стабильность ветки на основе отчета? PASSED AT LEAST ONCE. Означает - есть ли у нас области, в которых мы долго (дольше недели или 3 дней) не можем успешно прогнать тесты. «Убирает шумы» от нестабильности инфраструктуры и единичных выбросов.
- 57. 58 Отчет о результатах автотестов Метрика стабильности PASSED AT LEAST ONCE
- 58. Новый отчет сокращает время анализа с 2 часов до 30 минут Sexy look
- 59. Баланс тестов 60 GUI, Integration Tests Module / API Tests Unit Tests Manual Tests Какой баланс тестов у нас? Достаточно много интеграционных тестов, но они дают нам быструю локализацию за счет Central Logging Большинство API, а не GUI • Надежнее • Быстрее • Удобнее в поддержке
- 60. Сложность написания АТ 1. Подготовка тестовых данных – 40% 2. Написание теста – 20% 3. Отладка – 40% 1. Подготовка сложных данных может занимать по трудозатратам дни, календарно – недели (из-за багов смежных ф-лов и т.д.) 2. Вопрос с отладкой теста, который в ходе своей работы изменяет данные достаточно сложный. В дальнейшем мы придумали отладку на Dev-стенде
- 61. Подтвердили концепции Изоляция Нагенерировали абонентов по командам Подтвердили и использовали концепцию «1 тест = 1 абонент» Метаданные Приняли решение все метаданные заводить через одного человека и никому больше не менять
- 62. Добавляем автотесты ТС DEV НEстабильный Автоматизированная установка билда и прогон модульных автотестов. ТС DEV Барьер ТС модуля А ТС модуля С DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов. А B C D B CСистема B не имеет модульных автотестов Новые версии систем (билды) A, B, C Очередь билдов к проверке А B C Мы перешли к ежедневной стабилизации релиза
- 63. 64 Разработка — основной ответственный за стабильность. Версия не передается дальше, если не проходит внутреннее качество. До появления модульщиков была задача только написать код. С модульщиками – проверить насколько возможно систему. Сейчас цель – работоспособность всего нового кода и стабильность регресса. В том числе и интеграционная.
- 64. 65 Цель: MAIN — это стабильная версия, всегда готовая всегда к выпуску в продакшен. Меняем подход к работе с MAIN • не выкладывать код в ветку, пока он не будет целостно завершен (для этого можно держать его локально, в шелве или тимворке) • разбивать задачи так, чтобы скажем раз в день вы чекинили целостный кусок работы, который за ночь подружится с другими кусками/командами • при необходимости поломать внешнее АПИ, нужно будет сначала выставить новое, затем убедиться что все потребители на него перешли, затем удалить старое (обычно в следующем релизе) • что-то еще
- 65. 66 Сломанный регресс MAIN — это авария в производстве, решается с нулевым приоритетом. Фокус всей компании на стабильности MAIN. Отчеты MAIN на планерках производства, на еженедельных планерках производства и ИК. Остановка производства, любых работ и починка аварии. Подобная критичность у всех элементов конвейера билдов.
- 66. Вспомним проблематику Релизная политика Пиковая нагрузка по багам НФ и регресса в конце релиза (за фазой разработки), блокеры тестирования Фаза разработки Как сейчас Как хотелось бы
- 67. 68 АФ DEV Пр. ФТТЕСТ Пр. регресс Тираж Vision D1 Пр. ФТ Т1 Пр. регресс ТиражA2 D2 Т2 A3 D3 Т3 ТЕСТ DEMO A1 Спринты «Agile-подход» «Continuous Delivery» «Canary Releases» Целевая схема Текущая схема Производство 2.0 Continuous Delivery + Agile
- 70. CD экономит трудозатраты и сокращает календарь релизов. На примере релиза 5.2: o не пропустили баги, которые бы полностью заблокировали (не работает базовый процесс из смоук-тестсета) тестирование больше 20 раз Пример: 1. тестовый билд ОКАТа не менее 13 раз позволил оперативно обнаружить ошибки в отгруженном функционале, баги в этом случае не заводили, и этим тоже сэкономили время 2. баги изменения построения корзины: отключали установку на стенд ФТ пока не стабилизировали БП на стенде DEV Заблокированное тестирование – это сдвиг окончания сроков тестирования как минимум на неделю**. Из-за таких недель в итоге сдвигаются даты тиража. o вместо 350 тестов внутреннего регресса откатили 128 тестов, вместо двух откатов сделали один (из-за наличия автотестов) Экономия времени команды тестирования не менее 420 часов *** o сократили регрессионные проверки задачи функционального тестирования Пример: задача 1059196, примерно на 40 часов **** Итого CD в этой части сократил календарь 5.2 минимум на 1 неделю и сэкономили 460 чч Сокращение затрат Регресс 71
- 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
- 72. Автотесты сокращают затраты на выпуск релиза за счет сокращения затрат на модульное тестирование o Не нужно проводить трудоемких разборов доработок на предмет «на что могло повлиять» o В модульном тестировании можно не проводить трудоемких тестов для проверки регресса (особенно актуально по большим БП: расторжение, смена владельца, перенос ПО, смены ТП, ДУУ) o На этапе модульного тестирования можно сократить объем регрессионных тестов (особенно актуально по большим БП: расторжение, смена владельца, перенос ПО, смена ТП, ДУУ) o Есть возможность сравнивать логи прохождения теста до исправлений и после, что сокращает затраты на локализацию бага • Это ускоряет локализацию, т.к. легче найти, что было изменено Основная часть автотестов разрабатывалась в 5.2, поэтому экономия времени сможем посчитать в очередных релизах. При этом даже сейчас в 5.2, на примере команды OCF видим, что покрытие автотестами нам поможет в 5.2 не потратить 40 чч на регресс по задаче 1083900. Сокращение затрат Модульное тестирование 73
- 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
- 74. Исправлять баги, найденные автотестами, дешевле CD упрощает и облегчает процесс – не все баги заводятся в ТФС (особенно с модульных тестовых стендов), а исправляются сразу. На примере команды Оcat: за декабрь 2015 найдено 19 багов, которые правились без заведения в ТФС Сокращение затрат Стоимость бага 75
- 75. CD экономит время интеграции с помощью автоустановок o Автоустановки на стенд o Информация об установке исправления на стенд теперь пишется в баг, не надо искать по TFS деплойменты o Сократили количество ручных скриптов Экономия времени интеграции составила около 100 чч * (в релизе 5.2) + Упростили производственный процесс на фазе разработки: отказались вообще от процесса заведения в ТФС воркайтемов ship, deployment. Соответственно это привело к экономии времени разработки (на создание шипа), тестирования на анализ шипов и заведение деплойментов. Сокращение затрат Интеграция (автоустановки) 76
- 76. Аккумулируя предыдущие слайды – только в релизе 5.2 экономия времени составила 1900чч и больше месяца в производственном календаре. За счет того, что: o Меньше багов на начальном этапе стабилизации, релиз поступает в тестирование с частично проверенным регрессом o Меньше откатов и регрессионных проверок o В 3 раза дешевле локализация и исправление багов (стоимость бага сокращается с 6чч до 2 чч): раньше 4чч разработки + 1ч тестирования + 1ч интеграции, теперь только 2чч разработки Сокращение затрат Общий итог 77
- 77. Автотесты улучшают качество выпускаемых доработок o Можем выбирать более качественные решения, т.к. не боимся влияния на регресс, его проверят автотесты o В процессе создания тестов производим рефакторинг легаси-кода o Пока мы писали новые тесты, мы находили и исправляли баги в коде** o На примере команды OCF хрупкость модуля* снизилась в 2 раза относительно прошлых релизов и составила 5% o Коэффициент допрохода тестов в 5.2 равен примерно 2. По данному коэффициенту можно судить о стабильности релиза (по информации от тестирования: "Обычно 1 к 2 - очень хорошо, максимально бывало 1 к 4"): 2-3 - релиз стабилен, от 3 и выше - релиз нестабилен. То есть релиз, который мы выпустили из ветки MAIN, оказался стабильным. Качество 78
- 78. o Составлены стратегии автотестирования для каждого модуля o Процесс написание автотестов встроен в процесс разработки (новый функционал всегда идет с АТ, также покрываем тестами сложные баги) o Во многих командах существенно поднята компетенция по написанию автотестов o Всегда актуальная документация в виде тестов Баги более равномерно размазываются по итерации разработки и стабилизации и не заваливают пиково в конце как раньше. Массовых проблем в принципе нет, находятся только точечные баги в конкретных кейсах. Процессные достижения 79
- 79. o Production-quality tests. Ручным тестированием как правило занимались только модульное тестирование. Автотесты пишет вся команда o Мотивация модульных тестировщиков. Существенно веселее, чем ручное тестирование. «Мотивитует» к изучению основ программирования o Упрощен ввод новых разработчиков в команду. Можно дать задачу покрыть процесс тестами – естественным образом придется разобраться в технологиях, структуре проектов, составе модулей на ограниченном функционале, при этом сразу охватив и поняв весь БП, начать от простых кейсов, постепенно переходя к сложным (а не ковырять какой-то баг, не понимая, что и для чего исправляется) o Команды расширили свои знания по другим системам, т.к. приходиться делать настройки и подготовку данных для тестов o Эффект накопления и улучшения данных на основе Dev-стенда. Все затраты по его настройке, ведения задач остаются и поддерживаются постоянно. Не выбрасываются в конце каждого релиза или для конкретного проекта/Заказчика Дополнительные преимущества 80
- 80. Подтверждение концепции. Анализ простоев тестирования в 5.2 показал, что барьерный стенд исключит их появление Простой тестирования – это ситуация, когда вся команда тестирования не может проходить тесты (из- за неработающих критичных БП, не поднимающихся служб). На примере 5.2: o 1083578 не запускается служба СМ o 1080247 не открывалась форма ДУУ, не запрашивался баланс o 1082355 не стартует служба FORIS.SPA.SA.HLR.NSN o 1073962 ,1070756 не работает ДУУ o 1061114 ошибка ДУУ o и т.п. Ни один из билдов не прошел бы барьерный стенд. Барьерный стенд 81
- 81. Распределение багов регресса, найденных на разных стадиях релиза: от 5.0.3.1 (1.5 года назад) к 5.3 (полгода назад) Прогресс в одной картинке 82
- 82. Подтверждение концепции. Анализ простоев тестирования в 5.2 показал, что барьерный стенд исключит их появление Простой тестирования – это ситуация, когда вся команда тестирования не может проходить тесты (из- за неработающих критичных БП, не поднимающихся служб). На примере 5.2: o 1083578 не запускается служба СМ o 1080247 не открывалась форма ДУУ, не запрашивался баланс o 1082355 не стартует служба FORIS.SPA.SA.HLR.NSN o 1073962 ,1070756 не работает ДУУ o 1061114 ошибка ДУУ o и т.п. Ни один из билдов не прошел бы барьерный стенд. 83 Еще немного про выращивание
- 83. 84 Команда развития, постоянное переосмысление и движение вперед
- 84. 85 Тиражирование концепций, изменение парадигм, внутренние семинары, вовлечение
- 85. 86 Ежедневная работа с агентами изменений, тимлидами Стратегии автотестирования каждого модуля Процесс написание автотестов встроен в процесс разработки (новый функционал всегда идет с АТ, также покрываем тестами сложные баги) Поднимаем компетенции по написанию автотестов у каждого участника команды (разработчики и модульщики)
- 86. 87 А может KPI? Процент багов регресса, которые должны находиться с помощью автотестов технологии Continuous Delivery. Например 70%.
- 87. 88 Постоянное улучшение, правильно выбранные рычаги и обратные связи
- 89. Достроить конвейер качества и перевести его в «облако». Нужна гибкость 90 ТС DEV Стабильный Автоматизированная установка билда и прогон модульных автотестов. ТС DEV Барьер А B C ТС модуля А ТС модуля С Автоматизированная установка очередного билда и прогон интеграционного smoke-тестсета + API-тестов модуля. Стенд ежедневно пересоздается из стабильного TC DEV. Стабильный DEV-cтенд для ручного тестирования, разработки новых тестов. Автоматизированная установка успешных билдов и прогон интеграционного sаnity-тестсета + всех модульных API-тестов. А B C D B CСистема B не имеет модульных автотестов Новые версии систем (билды) A, B, C Очередь билдов к проверке К о н в е й е р б и л д о в , к о н в е й е р к а ч е с т в а
- 90. 91 Vision D1 Пр. ФТ Т1 Пр. регресс ТиражA2 D2 Т2 A3 D3 Т3 ТЕСТ DEMO A1 Спринты «Agile-подход» «Continuous Delivery» Умощнить базу регресс-автотестов и перейти на применение Agile-практик 91
- 91. Распространить Continuous Delivery на все продукты Компании и ИТ-ландшафта 92 FORIS SCP НКИПBSSmBP BMS
- 92. Выживает самый гибкий и быстрый “Many industry watchers believe that DevOps has been an essential component in their meteoric growth.” Из отчета New Relic – Navigating DevOps
- 93. 94 Цель: Continuous Delivery — в ДНК компании. Спасибо! Бирюков Павел pbiryukov@gmail.com pavel.biryukov