- PVSM.RU - https://www.pvsm.ru -
[1] При разработке и тестировании какого-либо продукта появляется много рутинной работы. Чтобы избежать ошибок, связанных с человеческим фактором, мы используем AIDA.
AIDA (англ. Automated Interactive Deploy Assistant) — это учётная запись, значительно облегчающая работу с Git, TeamCity и JIRA.
Сегодня речь пойдет о том, как с её помощью нам удалось автоматизировать многие рабочие процессы.
В первую очередь мы вспомним об используемой в Badoo системе контроля версий, далее расскажем о том, как было автоматизировано создание веток релиза и осуществлено автоматическое слияние веток в Git, поговорим о существенной помощи AIDA в работе с JIRA (контроль и изменение статуса задач, заполнение полей) и ТeamCity (непрерывная интеграция и развёртывание на тестовое окружение).
В качестве системы контроля версий Badoo использует Git. Особенность нашей модели состоит в том, что каждая задача разрабатывается и тестируется в отдельной ветке. Её название состоит из номера тикета в JIRA и свободного описания задачи.
Релиз мы собираем и тестируем из отдельной ветки, в которую сливаем завершённые задачи. Так как код на боевые серверы выкладывается два раза в день, то создаются две новые ветки для релиза.
Наименование у релизной ветки простое: build_{дата релиза}_{время}
Из такого имени всей команде известны дата и время релиза. Также на это время ориентируются хуки, запрещающие вносить изменения в релизную ветку. Например, разработчикам запрещено добавлять задачу в ветку релиза за два часа до выкладки на боевые серверы. Без такого ограничения команда QA не успевала бы проверять все задачи в ветке релиза.
Ветка master для нас является копией production. Как только build обновляет код на серверах, он сливается в ветку master. Также из этой ветки раскладываются срочные фиксы на площадке.
Данная схема отображена на рисунке:
Тестирование идет в несколько этапов:
Если с задачей в релизе что-то не так, то мы откатываем ветку с ней при помощи git rebase. Эта функция используется не случайно: нам не подходит revert, так как после отката релизная ветка сольётся в master, а ветки с задачами постоянно из него обновляются. В итоге, когда разработчик проблемной задачи обновит свою ветку, его код пропадёт, и придётся делать revert на коммит revert.
Из-за большого количества веток в описанной выше модели возникает множество задач на слияние веток, формирование релиза и контроль кода. Рассмотрим их автоматическое решение:
Для контроля разработки, формирования релиза и тестирования мы используем JIRA. Workflow во всех проектах полностью проработан и формализован. В процессе разработки и тестирования часть работы в баг-трекере выполняет AIDA.
В основном она помогает нам перемещать задачи либо отображает ту или иную информацию в них. Вот несколько примеров:
Также она помогает поменять статус задачи, если есть определенные резолюции:
AIDA сообщает нам обо всех своих действиях с задачами.
Данная автоматизация значительно упрощает работу с workflow и избавляет от рутинных действий.
При сборке и автоматическом развёртывании на тестовом окружении мы хотели полностью избавиться от рутинных действий, но приходилось вручную прописывать меняющиеся имена веток релиза в проектах CI-сервера. На данный момент TeamCity отлавливает изменения во всех ветках по заданной маске (в нашем случае это маска build_* ) и запускает сборку. К сожалению, существует одна проблема: мы не можем убрать из конфигурации проекта ветку default, и если туда приходят изменения, мы её просто игнорируем. При этом ветка вытягивается, а мы теряем ресурсы и время. Очень надеемся, что разработчики CI-сервера вскоре исправят эту проблему.
Ссылки на тикеты:
Support branch specification in the VCS trigger rule [2]
Ignore default VCS branch, only use branch specifications for change tracking [3]
Давайте посмотрим, что в итоге получается со сборкой и автоматическим развёртыванием:
Вся процедура занимает три минуты. Тесты выявляют только фатальные ошибки. При этом все unit-, авто- и функциональные тесты запускаются параллельно.
Сделано это для того, чтобы тестировщик как можно быстрее увидел задачу в тестовом окружении.
Давайте посмотрим, какие действия у нас автоматизирует AIDA:
AIDA умеет многое, но мы не останавливаемся на этом и хотим научить нашу помощницу следующим действиям:
Если вас заинтересует более подробный рассказ о каждом виде автоматизации, напишите об этом в комментариях и мы с удовольствие продолжим цикл статей на эту тему.
P.S Создавайте себе хороших помощников, которые не подведут вас в трудную минуту!
Автор: vchernov
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/27128
Ссылки в тексте:
[1] Image: http://habrastorage.org/storage2/4fd/6b4/2f8/4fd6b42f83fcb9a7e41065f1b1dd2a8a.jpg
[2] Support branch specification in the VCS trigger rule: http://youtrack.jetbrains.com/issue/TW-22291
[3] Ignore default VCS branch, only use branch specifications for change tracking: http://youtrack.jetbrains.com/issue/TW-24147
[4] Источник: http://habrahabr.ru/post/169417/
Нажмите здесь для печати.