При разработке и тестировании какого-либо продукта появляется много рутинной работы. Чтобы избежать ошибок, связанных с человеческим фактором, мы используем AIDA.AIDA (англ. Automated Interactive Deploy Assistant) — это учётная запись, значительно облегчающая работу с Git, TeamCity и JIRA.
Сегодня речь пойдет о том, как с её помощью нам удалось автоматизировать многие рабочие процессы.
В первую очередь мы вспомним об используемой в Badoo системе контроля версий, далее расскажем о том, как было автоматизировано создание веток релиза и осуществлено автоматическое слияние веток в Git, поговорим о существенной помощи AIDA в работе с JIRA (контроль и изменение статуса задач, заполнение полей) и ТeamCity (непрерывная интеграция и развёртывание на тестовое окружение).
Git Workflow
В качестве системы контроля версий Badoo использует Git. Особенность нашей модели состоит в том, что каждая задача разрабатывается и тестируется в отдельной ветке. Её название состоит из номера тикета в JIRA и свободного описания задачи.
Релиз мы собираем и тестируем из отдельной ветки, в которую сливаем завершённые задачи. Так как код на боевые серверы выкладывается два раза в день, то создаются две новые ветки для релиза.
Наименование у релизной ветки простое: build_{дата релиза}_{время}
Из такого имени всей команде известны дата и время релиза. Также на это время ориентируются хуки, запрещающие вносить изменения в релизную ветку. Например, разработчикам запрещено добавлять задачу в ветку релиза за два часа до выкладки на боевые серверы. Без такого ограничения команда QA не успевала бы проверять все задачи в ветке релиза.
Ветка master для нас является копией production. Как только build обновляет код на серверах, он сливается в ветку master. Также из этой ветки раскладываются срочные фиксы на площадке.
Данная схема отображена на рисунке:
Тестирование идет в несколько этапов:
- Devel — первый этап тестирования, каждая задача проверяется на development environment, её смотрят на тестовых базах и запускают unit-тесты.
- Shot — проверяется задача в боевом окружении. Физически это папка на сервере, в которую выкачивается ветка репозитория и настраивается nginx; имеет свой домен первого уровня — .shot. На этом этапе генерируются переводы на основные языки.
- Staging — релиз тестируется в боевом окружении, переводится на все языки, полностью мониторится. Повторно проверяются все задачи.
Если с задачей в релизе что-то не так, то мы откатываем ветку с ней при помощи git rebase. Эта функция используется не случайно: нам не подходит revert, так как после отката релизная ветка сольётся в master, а ветки с задачами постоянно из него обновляются. В итоге, когда разработчик проблемной задачи обновит свою ветку, его код пропадёт, и придётся делать revert на коммит revert.
AIDA и Git
Из-за большого количества веток в описанной выше модели возникает множество задач на слияние веток, формирование релиза и контроль кода. Рассмотрим их автоматическое решение:
- Прежде всего AIDA создаёт ветку build. Она «слушает» ветку master, и если предыдущая ветка релиза сливается в master, то создается новая ветка.
- Затем в новую ветку релиза каждую минуту сливаются ветки с уже выполненными, протестированными и соответствующими шаблону в JIRA задачами. Если при слиянии происходит конфликт, разработчику и релиз-инженеру приходит уведомление о нём, а задача перенаправляется разработчику.
- Так как ветка master является копией кода, разложенного на боевых серверах, и в неё добавляются изменения, её нужно постоянно объединять с веткой релиза. AIDA выполняет это слияние, если зафиксировалось изменение в ветке master. При конфликте появляется соответствующее сообщение.
- Если после слияния с веткой релиза разработчик добавит изменение в ветку с задачей, то этот коммит будет пойман и AIDA сообщит об этом.
AIDA и JIRA
Для контроля разработки, формирования релиза и тестирования мы используем JIRA. Workflow во всех проектах полностью проработан и формализован. В процессе разработки и тестирования часть работы в баг-трекере выполняет AIDA.
В основном она помогает нам перемещать задачи либо отображает ту или иную информацию в них. Вот несколько примеров:
- разработчик фиксирует изменения кода в центральном репозитории, статус тикета автоматически меняется с Open на In Progress;
- если для тикета создается Shot (код выкладывается в отдельное боевое окружение), то статус задачи автоматически меняется на In Shot;
- Тикет автоматически открывается повторно при откате задачи из релизной ветки;
- если задача прошла процедуру проверки кода и после этого следует изменение в ветке, то тикет возвращается на проверку.
Также она помогает поменять статус задачи, если есть определенные резолюции:
- Fixed & Deploy on Production — тикет автоматически меняет статус на On Production
AIDA сообщает нам обо всех своих действиях с задачами.
Данная автоматизация значительно упрощает работу с workflow и избавляет от рутинных действий.
AIDA и TeamCity
При сборке и автоматическом развёртывании на тестовом окружении мы хотели полностью избавиться от рутинных действий, но приходилось вручную прописывать меняющиеся имена веток релиза в проектах CI-сервера. На данный момент TeamCity отлавливает изменения во всех ветках по заданной маске (в нашем случае это маска build_* ) и запускает сборку. К сожалению, существует одна проблема: мы не можем убрать из конфигурации проекта ветку default, и если туда приходят изменения, мы её просто игнорируем. При этом ветка вытягивается, а мы теряем ресурсы и время. Очень надеемся, что разработчики CI-сервера вскоре исправят эту проблему.
Ссылки на тикеты:
Support branch specification in the VCS trigger rule
Ignore default VCS branch, only use branch specifications for change tracking
Давайте посмотрим, что в итоге получается со сборкой и автоматическим развёртыванием:
- Проект в TeamCity настроен на ветки с маской build_*.
- После изменений в ветке релиза запускается автоматическая сборка.
- При успешном выполнении стартует скрипт развёртывания на тестовые сервера.
- С помощью быстрых smoke-тестов ( используем простой curl) проверяется тестовое окружение.
- Если тесты не проходят, версия релиза помечается как плохая и происходит откат на предыдущую (хорошую) версию релиза.
Вся процедура занимает три минуты. Тесты выявляют только фатальные ошибки. При этом все unit-, авто- и функциональные тесты запускаются параллельно.
Сделано это для того, чтобы тестировщик как можно быстрее увидел задачу в тестовом окружении.
Итоги
Давайте посмотрим, какие действия у нас автоматизирует AIDA:
- Работает с Git, создаёт ветки, сливает их, предупреждает нас, если что-то идёт не так.
- Взаимодействует с JIRA, автоматически меняет статусы и обновляет информацию в задачах.
- Помогает TeamCity запускать скрипты, тесты и производить развёртывание на тестовую среду.
AIDA умеет многое, но мы не останавливаемся на этом и хотим научить нашу помощницу следующим действиям:
- автоматическое применение патчей для Git из специального интерфейса для сбора, контроля, учёта и формализации патчей, с полным перечнем информации и автоматическим оповещением;
- полностью автоматический rebase задачи из build-ветки по смене статуса тикета в JIRA;
- автоматический запуск unit-тестов для каждой ветки задачи в момент её завершения и после изменения статуса в баг-трекере с последующим отчётом в JIRA.
Если вас заинтересует более подробный рассказ о каждом виде автоматизации, напишите об этом в комментариях и мы с удовольствие продолжим цикл статей на эту тему.
P.S Создавайте себе хороших помощников, которые не подведут вас в трудную минуту!
