Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Highway to Сontinuous Integration, Денис Трифонов (2GIS)

1,307 views

Published on

Доклад Дениса Трифонова на HighLoad++ 2014.

Published in: Internet
  • Be the first to comment

Highway to Сontinuous Integration, Денис Трифонов (2GIS)

  1. 1. Highway to Continuous Integration Денис Трифонов
  2. 2. Обо мне Инженер по качеству в команде Continuous Delivery 2
  3. 3. api.2gis.ru —  Справочник организаций —  Геоданные —  Карты —  Транспорт (скоро) 3
  4. 4. Справочное API —  Версии 1.3 и 2.0 —  7 приложений + Core на Yii Framework (PHP) —  Функциональные и юнит­тесты —  Git Flow —  20 смежных команд 4
  5. 5. Проблемы —  Разработчики коммитят бажный код —  Тестировщики не находят баги или не успевают проверить фичу 5
  6. 6. Последствия —  Узнаем о багах при подготовке к релизу —  Релиз затягивается или переносится 6
  7. 7. „Мы хотим выявлять баги по мере готовности фич, а не при подготовке к релизу“
  8. 8. 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. Martin Fowler “ 8
  9. 9. Continuous Integration — не решит всех проблем разработки, но позволит выявлять баги на этапе программирования фичи 9
  10. 10. Continuous Integration
  11. 11. Интеграционная сборка ≤ 5 min
  12. 12. Что у нас есть —  Ветка с новой фичей —  Тесты —  Система деплоя 12
  13. 13. Этапы интеграционной сборки 1. Деплой фичи 2. Выполнение тестов —  Когда все хорошо, сливаем фичу в мастер —  Когда что­то упало, сообщаем о проблеме 13
  14. 14. 6 часов
  15. 15. Время этапов сборки —  Деплой за 3 минуты —  Тесты за 5 часов 57 минут 16
  16. 16. 12 000 тестов
  17. 17. Анализ выполнения тестов —  Максимальное время выполнения одного теста 2 минуты —  Среднее время выполнения одного теста 1,5 секунды —  PHPUnit использует одно ядро (из 16) процессора 18
  18. 18. ParaTest github.com/brianium/paratest Поддержка параллельного выполнения тестов на PHPUnit 19
  19. 19. Пример $ paratest -p 16 --phpunit ./phpunit -c ./phpunit.xml ./tests 20
  20. 20. 50 минут
  21. 21. Ищем компромисс —  Долгая интеграция, но стабильный мастер —  Быстрая интеграция, но возможные баги в мастере 22
  22. 22. Исключаем тесты —  Оставляем только приоритетные тесты —  Оставляем только формат JSON (убрали JSONP и XML) Итого: 1500 тестов 23
  23. 23. 5 минут
  24. 24. Еще быстрее? Если не было изменений в окружении, то достаточно обновить только приложения 25
  25. 25. Деплой окружения и приложений —  Мелкие правки с помощью Phing (только приложения) —  Большие правки с помощью Chef (приложения + окружение) 26
  26. 26. 3 минуты
  27. 27. Лень побеждает У нас есть автоматизированная сборка, но после нее приходится самому писать в JIRA о смене статуса фичи 28
  28. 28. Интеграция с JIRA —  Комментарий в тикете об автоматическом мерже веток —  Метка у тикета при попадании в мастер 29
  29. 29. JIRA REST API Client github.com/chobie/jira­api­restclient API­клиент для JIRA на PHP 30
  30. 30. Пример (PHP) $client->addComment($jiraIssue, $jiraComment); $client->editIssue($jiraIssue, [ 'fields' => ['labels' => $labels] ]); 31
  31. 31. Интеграционная сборка в работе Feature Branch -> Deploy -> Priority Tests -> Merge to Master -> Mark Issue in JIRA 32
  32. 32. Профит Разработчик спустя три минуты после готовности фичи может слить ее в мастер 33
  33. 33. Но... Мы все также неуверенны в мастере 35
  34. 34. Регрессионная сборка Master Branch -> Deploy -> Full Tests 36
  35. 35. Запускаем регрессионную сборку два раза в день
  36. 36. Регрессия перед релизом Master Branch -> RC -> Deploy -> Full Tests -> Merge to Stable -> Mark Issues in JIRA 38
  37. 37. Профит Мастер становится стабильным спустя половину дня вместо пяти 39
  38. 38. Как так?! Упала миграция на бою, хотя регрессия прошла успешно 42
  39. 39. Задача Перед регрессией нужно полностью восстанавливать исходное состояние окружения 43
  40. 40. Куда поместить окружение —  Open Stack —  Virtual Box —  Docker —  Другие технологии контейнеризации и виртуализации 44
  41. 41. Архитектура в Open Stack —  API­нода —  Нода с тестами —  Любая нода по требованию за 1 минуту 45
  42. 42. Обновленная регрессия ... -> Revert VM -> Deploy -> ... -> Update Snapshot 46
  43. 43. Профит Во время регрессии деплоим так же, как на бою 47
  44. 44. Понедельник день тяжелый Вышел новый сотрудник, начал настраивать рабочее окружение и вылетели ошибки во время разворачивания API 48
  45. 45. Сборка деплоя с нуля VM Up -> Deploy -> Import Data -> Tests -> VM Destroy 49
  46. 46. Профит Мы уверены, что в любое время можем развернуть API без ошибок 50
  47. 47. Итого 1. Интеграционная сборка 2. Регрессионная сборка 3. Сборка деплоя с нуля 51
  48. 48. Итого Выявляем баги не при подготовке релиза, а по мере готовности фич. Сборки падают, а значит выполняют свои задачи. 52
  49. 49. Результат —  Мы находим проблемы спустя три минуты вместо пяти дней —  Мастер становится стабильным спустя половину дня вместо пяти 53
  50. 50. Вывод Continuous Integration помогает выявлять баги на этапе программирования фичи 54
  51. 51. Continuous Integration — разработка без скоростных ограничений
  52. 52. Денис Трифонов de.trifonov@2gis.ru dentrifonov.github.io Спасибо!

×