AIDA. Автоматизация работы с Git, JIRA и TeamCity

При разработке и тестировании какого-либо продукта появляется много рутинной работы. Чтобы избежать ошибок, связанных с человеческим фактором, мы используем 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 and 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

Давайте посмотрим, что в итоге получается со сборкой и автоматическим развёртыванием:

1. Проект в TeamCity настроен на ветки с маской build_*.
2. После изменений в ветке релиза запускается автоматическая сборка.
3. При успешном выполнении стартует скрипт развёртывания на тестовые сервера.
4. С помощью быстрых smoke-тестов ( используем простой curl) проверяется тестовое окружение.
5. Если тесты не проходят, версия релиза помечается как плохая и происходит откат на предыдущую (хорошую) версию релиза.

Вся процедура занимает три минуты. Тесты выявляют только фатальные ошибки. При этом все unit-, авто- и функциональные тесты запускаются параллельно.
Сделано это для того, чтобы тестировщик как можно быстрее увидел задачу в тестовом окружении.

Итоги

Давайте посмотрим, какие действия у нас автоматизирует AIDA:

1. Работает с Git, создаёт ветки, сливает их, предупреждает нас, если что-то идёт не так.
2. Взаимодействует с JIRA, автоматически меняет статусы и обновляет информацию в задачах.
3. Помогает TeamCity запускать скрипты, тесты и производить развёртывание на тестовую среду.

AIDA умеет многое, но мы не останавливаемся на этом и хотим научить нашу помощницу следующим действиям:

• автоматическое применение патчей для Git из специального интерфейса для сбора, контроля, учёта и формализации патчей, с полным перечнем информации и автоматическим оповещением;
• полностью автоматический rebase задачи из build-ветки по смене статуса тикета в JIRA;
• автоматический запуск unit-тестов для каждой ветки задачи в момент её завершения и после изменения статуса в баг-трекере с последующим отчётом в JIRA.

Если вас заинтересует более подробный рассказ о каждом виде автоматизации, напишите об этом в комментариях и мы с удовольствие продолжим цикл статей на эту тему.

P.S Создавайте себе хороших помощников, которые не подведут вас в трудную минуту!