Embed Size (px)
Citation preview
Идеальный процесс разработки Взаимодействие с командой тестирования
План лекции
2
Автоматизированные системные (функциональные) тесты
Юнит-тесты Интеграционные тесты Тесты производительности
В предыдущих сериях
3
Как теперь будет выглядеть
процесс разработки?
4
Разработка
на локальной машине
Локальная сборка
Локальный прогон
Юнит-тестов
Интеграция с общей веткой
Функциональное тестирование
Процесс разработки
5
Welcome to Integration Hell
6
Что такое
идеальный процесс?
7
Удобный Способствует повышению качества Снижает риски Ускоряет разработку Прозрачен для всей команды Максимально автоматизирован ?
Идеальный процесс разработки
8
Непрерывная интеграция — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.
Википедия
Continuous Integration. Непрерывная интеграция
9
"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible."
M. Fowler
Continuous Intergration. Непрерывная интеграция
10
Как можно более частая интеграция кода Непрерывное тестирование изменений
Непрерывная интеграция. Идея
11
Исходный код и все, что необходимо для сборки и тестирования проекта, хранится в репозитории системы контроля версий
Чекаут из репозитория, сборка и тестирование проекта автоматизированы
Требования к проекту
12
Code-review (opt.)
CI процесс
13
Continuous Integration.
Преимущества использования
• Проблемы интеграции выявляются и
исправляются быстро, что оказывается
дешевле
• Немедленный прогон модульных тестов для
свежих изменений
• Постоянное наличие текущей стабильной
версии вместе с продуктами сборок — для
тестирования, демонстрации, и т. п.
14
CI процесс
Code-review (opt.)
15
Система контроля версий – инструмент, облегчающий работу с изменяющимися данными. Предоставляет возможность хранить несколько версий одного документа, при необходимости вернуться к более ранней версии, определить кто и когда внес то или иное изменение, etc.
Система контроля версий. Version Control System
16
Легкий доступ к коду Обеспечивает версионность Облегчает совместную разработку Возможность автоматизировать процессы сборки,
ревью, запуска тестов
Система контроля версий. Преимущества использования
17
1. Редкие коммиты -> рискуем потерять часть изменений, реже интегрируемся Решение: Частые коммиты в течение дня
2. Массовые коммиты перед уходом с работы -> рискуем задержать коллег из-за сломанной сборки Решение: Не коммитить после N часов
Система контроля версий. Антипаттерны использования
18
Git Subversion CVS ClearCase ... http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Система контроля версий. Инструменты
19
Code-review (opt.)
CI процесс
20
Код-ревью – систематический просмотр кода с целью найти и исправить ошибки, допущенные на начальном этапе разработки. Цель - повышение качества кода и обмен опытом между разработчиками. Виды Pre-commit review (email/over-the-shoulder) Post factum Выборочное ревью
Code-review. Код-ревью
21
Плюсы: Способствует обнаружению ошибок Возможность получить фидбек о стиле программирования и
выборе алгоритмов Обмен опытом Развивает командность Единообразность кода Минусы: Требует инвестиций на начальном этапе
Код-ревью. Плюсы и минусы
22
Ошибки обращения к данным Ошибки логических и арифметических операций Использование сложных конструкций Ошибки в логике программы Стилевые ошибки Опечатки
Код ревью. Типы ошибок
23
Проблемы адресации Индексы массивов Объявление переменных Размер и тип Именование переменных …
Ошибки обращения к данным
24
Переполнения Потеря точности Деление на ноль Ошибки в операторах сравнения …
Ошибки вычислений
25
Именование переменных Форматирование Документирование кода …
Стилевые ошибки
26
Бесконечные циклы Race conditions Утечки памяти …
А также..
27
Хорошо
Быстро
Конструктивно
Объективно
Позитивно
Плохо
Навязывание личных предпочтений
Переход на личности
Код-ревью. Основные принципы
28
Код-ревью тормозит процесс разработки -> негативное отношение к процессу ревью Решение: Проводить параллельно с тестированием, у задач на код-ревью – 1 приоритет
Код-ревью. Антипаттерны
29
VCS plug-ins E-mail
http://en.wikipedia.org/wiki/List_of_tools_for_code_review
Код-ревью. Инструменты
30
Code-review (opt.)
CI процесс
32
Компиляция Сборка Выполнение модульных тестов Формирование документации и release notes
Автоматическая сборка
33
Редкие сборки -> поздно обнаруживаем баги Решение: В идеале - сборка после каждого коммита Допускается сборка по расписанию несколько раз в день, если сборка+прогон модульных тестов занимает много времени NB! Возможно, это проблема и с ней надо разобраться отдельно
Автосборка. Антипаттерны
34
Сборка на машине разработчика -> проблема WOMM Решение: Сборка должна производиться в целевой среде
Автосборка. Антипаттерны
35
Maven Ant Make Gant MSBuild … http://en.wikipedia.org/wiki/List_of_build_automation_software
Автосборка. Инструменты
36
Code-review (opt.)
CI процесс
37
Выполнение модульных тестов при сборке Прогон функциональных/нагрузочных/etc автотестов для
каждой сборки
Непрерывное тестирование
38
Code-review (opt.)
CI процесс
39
Необходима автоматическая отправка информации о состоянии сборки разработчикам. Средства: Email, SMS, дашборды, нотификация в мессенджер
Непрерывная обратная связь. Continuous Feedback
40
Слишком много сообщений о проваленной сборке -> Письма заносятся в спам-фильтр.
Решение: Сообщения должны быть адресными – тому, кто сломал
сборку.
Обратная связь. Антипаттерны
41
Неинформативные отчеты -> уходит много времени на понимание проблемы
Решение: В сообщении должна содержаться необходимая и
достаточная информация о проваленной сборке/тестах
Обратная связь. Антипаттерны
42
Сборка всегда находится в сломанном состоянии, тесты не чинят.
Решение: «Зеленая» сборка - приоритет №1, pre-commit hook, мотивация
Антипаттерны применения CI
43
Проверка наличия изменений в репозитории Выполнение некоторых действий по триггеру
(наличие изменений, расписание) Поддержка нескольких инструментов сборки Поддержка нескольких VCS Предоставление отчетов, статистики, отправка
нотификаций Сохранение истории Панель управления задачами
Требования к CI серверу
44
Jenkins (Hudson)
CruiseControl
TeamCity
Bamboo
…
Инструменты CI
45
Что дальше?
46
Непрерывная доставка изменений в среду, где будет тестироваться бизнес-логика.
Непрерывная доставка. Continuous Delivery
47
“Continuous Delivery is about keeping your application in a state where it is always able to deploy into production.
Continuous Deployment is actually deploying every change into production, every day or more frequently.”
M. Fowler
Continuous Delivery VS Continuous Deployment
48
Непрерывное развертывание – выпуск в продакшн-среду изменений сразу, как только они готовы к выкладке.
Непрерывное развертывание. Continuous Deployment
49
Автоматизированная выкладка одной командой Только полностью готовые к выкладке фичи в production-ветке DevOps Чистота среды Маркировка каждой сборки Прогон всех проверок Использование обратной связи Возможность быстро откатить изменения
Непрерывное развертывание. Tips&Tricks
50
Взаимодействие с командой тестирования
51
Основная идея – у нас общая цель!
52
Тестирование увеличивает время до выкладки в продакшн
Тестировщики любят находить много багов Тестировщики обеспечивают качество Тестировщики отвечают за качество продукта Тестирование должно быть полностью
автоматизировано
Мифы о тестировании
53
Тестировщики должны иметь возможность протестировать приложение
Процесс разработки должен быть прозрачен для тестировщика (и наоборот) Работа с кодом Работа с требованиями Работа с багами
Эффективное взаимодействие
54
Тестопригодность – степень легкости и удобства тестирования, а также возможность проведения тестирования с использованием определенного инструмента или подхода.
Тестопригодность. Testability
55
Характеристики тестопригодного ПО:
управляемость: возможность перейти в любое состояние системы, подавая на вход разные стимулы
наблюдаемость: в каждый момент времени понимаем в каком состоянии находится система
изолируемость: тестируемый компонент может быть проверен в изоляции
разделение задач: тестируемый компонент имеет одно, вполне определенное назначение
автоматизируемость: возможность автоматизировать тестирование
Тестопригодность. Testability
56
Тестировщику необходим список изменений -> Все изменения должны быть отражены в ТЗ/Таск-трекере.
Управление требованиями и процесс разработки
57
Старайтесь относиться позитивно Учитесь на ошибках Все баги – через баг/таск-трекер Не накапливайте технический долг
Работа с багами
58
Баги в продакшне
59
Ошибка тестировщика Невозможность протестировать все Баг воспроизводится нестабильно (гейзенбаг) Несоответствие тестовой среды продакшн-среде Ошибка при выкладке
60
Баги в продакшн-среде: причины
Фикс NB! Фикс должен быть протестирован перед выкладкой Анализ причин Меры по предотвращению багов в будущем
61
Баги в продакшн-среде: действия
Процесс важен для достижения результата Процесс должен существовать не ради процесса Процесс должен быть удобен всем и способствовать
эффективной работе команды
62
Резюме
1. http://martinfowler.com/articles/continuousIntegration.html 2. http://www.thoughtworks.com/continuous-delivery 3. Непрерывное развертывание ПО, Джез Хамбл, Дейвид Фарли 4. http://refcardz.dzone.com/refcardz/continuous-integration#refcard-download-social-
buttons-display 5. http://martinfowler.com/bliki/FeatureBranch.html 6. http://martinfowler.com/bliki/FeatureToggle.html 7. http://itrevolution.com/devops-culture-part-1/
Материалы
63
