9. Continuous Integration.
Непрерывная интеграция
Непрерывная интеграция — это практика разработки
программного обеспечения, которая заключается в
выполнении частых автоматизированных сборок
проекта для скорейшего выявления и решения
интеграционных проблем.
Википедия
9
10. Continuous Intergration.
Непрерывная интеграция
"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
10
12. Требования к проекту
Исходный код и все, что необходимо для сборки и
тестирования проекта, хранится в репозитории
системы контроля версий
Чекаут из репозитория, сборка и тестирование
проекта автоматизированы
12
14. Continuous Integration.
Преимущества использования
• Проблемы интеграции выявляются и
исправляются быстро, что оказывается
дешевле
• Немедленный прогон модульных тестов для
свежих изменений
• Постоянное наличие текущей стабильной
версии вместе с продуктами сборок — для
тестирования, демонстрации, и т. п.
14
16. Система контроля версий.
Version Control System
Система контроля версий – инструмент, облегчающий работу с
изменяющимися данными. Предоставляет возможность хранить
несколько версий одного документа, при необходимости вернуться к
более ранней версии, определить кто и когда внес то или иное
изменение, etc.
16
17. Система контроля версий.
Преимущества использования
Легкий доступ к коду
Обеспечивает версионность
Облегчает совместную разработку
Возможность автоматизировать процессы сборки,
ревью, запуска тестов
17
18. Система контроля версий.
Антипаттерны использования
1. Редкие коммиты -> рискуем потерять часть
изменений, реже интегрируемся
Решение: Частые коммиты в течение дня
2. Массовые коммиты перед уходом с работы ->
рискуем задержать коллег из-за сломанной
сборки
Решение: Не коммитить после N часов
18
19. Система контроля версий.
Инструменты
Git
Subversion
CVS
ClearCase
...
http://en.wikipedia.org/wiki/Comparison_of_revision
_control_software
19
21. Code-review.
Код-ревью
Код-ревью – систематический просмотр кода с целью найти и
исправить ошибки, допущенные на начальном этапе
разработки.
Цель - повышение качества кода и обмен опытом между
разработчиками.
Виды
Pre-commit review (email/over-the-shoulder)
Post factum
Выборочное ревью
21
22. Код-ревью.
Плюсы и минусы
Плюсы:
Способствует обнаружению ошибок
Возможность получить фидбек о стиле программирования и
выборе алгоритмов
Обмен опытом
Развивает командность
Единообразность кода
Минусы:
Требует инвестиций на начальном этапе
22
23. Код ревью.
Типы ошибок
Ошибки обращения к данным
Ошибки логических и арифметических операций
Использование сложных конструкций
Ошибки в логике программы
Стилевые ошибки
Опечатки
23
24. Ошибки обращения к данным
Проблемы адресации
Индексы массивов
Объявление переменных
Размер и тип
Именование переменных
…
24
33. Автосборка.
Антипаттерны
Редкие сборки -> поздно обнаруживаем баги
Решение: В идеале - сборка после каждого коммита
Допускается сборка по расписанию несколько раз в день, если
сборка+прогон модульных тестов занимает много времени
NB! Возможно, это проблема и с ней надо разобраться отдельно
34
39. Непрерывная обратная связь.
Continuous Feedback
Необходима автоматическая отправка информации о
состоянии сборки разработчикам.
Средства: Email, SMS, дашборды, нотификация в
мессенджер
40
40. Обратная связь.
Антипаттерны
Слишком много сообщений о проваленной сборке ->
Письма заносятся в спам-фильтр.
Решение: Сообщения должны быть адресными – тому, кто сломал
сборку.
41
41. Обратная связь.
Антипаттерны
Неинформативные отчеты -> уходит много времени на понимание
проблемы
Решение: В сообщении должна содержаться необходимая и
достаточная информация о проваленной сборке/тестах
42
42. Антипаттерны применения CI
Сборка всегда находится в сломанном состоянии,
тесты не чинят.
Решение: «Зеленая» сборка - приоритет №1, pre-commit hook,
мотивация
43
43. Требования к CI серверу
Проверка наличия изменений в репозитории
Выполнение некоторых действий по триггеру
(наличие изменений, расписание)
Поддержка нескольких инструментов сборки
Поддержка нескольких VCS
Предоставление отчетов, статистики, отправка
нотификаций
Сохранение истории
Панель управления задачами
44
47. Continuous Delivery VS
Continuous Deployment
“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
48
52. Мифы о тестировании
Тестирование увеличивает время до выкладки в
продакшн
Тестировщики любят находить много багов
Тестировщики обеспечивают качество
Тестировщики отвечают за качество продукта
Тестирование должно быть полностью
автоматизировано
53
53. Эффективное взаимодействие
Тестировщики должны иметь возможность протестировать
приложение
Процесс разработки должен быть прозрачен для
тестировщика (и наоборот)
Работа с кодом
Работа с требованиями
Работа с багами
54
55. Тестопригодность.
Testability
Характеристики тестопригодного ПО:
управляемость: возможность перейти в любое состояние
системы, подавая на вход разные стимулы
наблюдаемость: в каждый момент времени понимаем в
каком состоянии находится система
изолируемость: тестируемый компонент может быть
проверен в изоляции
разделение задач: тестируемый компонент имеет одно,
вполне определенное назначение
автоматизируемость: возможность автоматизировать
тестирование
56
56. Управление требованиями и
процесс разработки
Тестировщику необходим список изменений ->
Все изменения должны быть отражены в ТЗ/Тасктрекере.
57
57. Работа с багами
Старайтесь относиться позитивно
Учитесь на ошибках
Все баги – через баг/таск-трекер
Не накапливайте технический долг
58
59. Баги в продакшн-среде:
причины
Ошибка тестировщика
Невозможность протестировать все
Баг воспроизводится нестабильно (гейзенбаг)
Несоответствие тестовой среды продакшн-среде
Ошибка при выкладке
60
60. Баги в продакшн-среде:
действия
Фикс
NB! Фикс должен быть протестирован перед
выкладкой
Анализ причин
Меры по предотвращению багов в будущем
61
61. Резюме
Процесс важен для достижения результата
Процесс должен существовать не ради процесса
Процесс должен быть удобен всем и способствовать
эффективной работе команды
62