Как повысить качество тестирования при помощи практик TBD

RU
#talks#testing#tbd#trunk-based-development

Конференция Dats.Team, Бишкек. 7 октября 2022. Коворкинг-центр «Ololo», бульвар Эркиндик 64Б. Около 30 человек оффлайн + 30 онлайн. Тайминг: 18:00–18:40.

Бэкап видео (OneDrive) · Бэкап видео (Wayback Machine) · Презентация (OneDrive)

Доклад про Trunk-Based Development (TBD) — подход, при котором вся разработка идёт в одной ветке, а мастер всегда готов к деплою.

Проблема долгоживущих веток

Начал с истории из своего проекта: команда оценила рефакторинг в месяц на двух человек, а в итоге получила монструозную ветку, которая жила 3,5 месяца и которую потом неделями мержили.

Параллельные фичи тестируются по отдельности, а на прод уезжает их слитая комбинация — то есть совсем не то, что тестировали. При мерже возникают конфликты (причём разруливает их «последний пришедший»), рефакторинг по всем веткам никто никогда не разносит, continuous integration по факту отсутствует.

Суть TBD

Вся разработка идёт в одной ветке — master, который всегда готов к деплою. Релизные ветки создаются только как точки отсечки, без разработки в них. Если в релизе нашли баг — фиксим в мастере и cherry-pick в релизную ветку (а не наоборот), чтобы фикс не потерялся.

Плюсы: меньше мержей и конфликтов, маленькие частые коммиты, прозрачный прогресс, проще делать рефакторинг, мастер всегда стабилен.

Как к этому прийти

  • Маленькие release-ready коммиты
  • Feature Toggles для незавершённой работы (релизные, экспериментальные, permission, ops). Лучшие практики: чем меньше тогглов — тем лучше, держать их выше по слоям логики, не забывать удалять, собирать телеметрию
  • Shift Left / Push Quality Upstream — ловить проблемы как можно раньше: код-ревью, статанализ (SonarQube), юнит- и интеграционные тесты, сканеры уязвимостей. Нужна правильная пирамида тестирования (много юнит-тестов, мало ручных) — иначе при TBD тестировщики просто умрут
  • Safe Deployment Techniques: Canary Releases (раскатка сначала на лояльных пользователей — аналогия с канарейками в шахте), Dark Launches (разделение деплоя и релиза — код может быть на проде, но «выключен» тогглом), Automated Release Gates в пайплайне

Главная мысль: TBD требует серьёзной автоматизации тестирования и деплоя, но взамён даёт стабильный мастер и быструю доставку изменений на прод.

Другие выступления того дня

Ссылки