При разработке и тестировании любого продукта появляется много рутинной работы.
Чтобы избежать человеческих ошибок, мы используем AIDA. АИДА (англ.
Automated Interactive Deploy Assistant) — это учетная запись, которая значительно упрощает работу с Git, TeamCity и JIRA. Сегодня мы поговорим о том, как с его помощью нам удалось автоматизировать многие рабочие процессы.
Прежде всего вспомним систему контроля версий, используемую в Badoo, затем поговорим о том, как было автоматизировано создание релизных веток и осуществлено автоматическое слияние веток в Git, поговорим о существенной помощи AIDA в работе с JIRA. (контроль и изменение статуса задач, заполнение полей) и TeamCity (непрерывная интеграция и развертывание в тестовую среду).
Рабочий процесс Git
Badoo использует Git в качестве системы контроля версий.Особенность нашей модели в том, что каждая задача разрабатывается и тестируется в отдельной ветке.
Его название состоит из номера заявки JIRA и свободного описания проблемы.
Мы собираем и тестируем релиз из отдельной ветки, в которую сливаем выполненные задачи.
Поскольку код загружается на рабочие серверы два раза в день, для выпуска создаются две новые ветки.
Название ветки релиза простое: build_{дата выпуска}_{время} По такому названию вся команда знает дату и время релиза.
В настоящее время также рассматриваются хуки, запрещающие внесение изменений в ветку выпуска.
Например, разработчикам запрещено добавлять задачу в ветку релиза за два часа до ее загрузки на продакшн-серверы.
Без такого ограничения у команды QA не было бы времени проверить все проблемы в ветке релиза.
Мастер-ветвь для нас — это копия производства.
Как только сборка обновляет код на серверах, он объединяется с основной веткой.
Срочные исправления на сайте также выкладываются из этой ветки.
Эта схема представлена на рисунке: 
Тестирование проходит в несколько этапов:
Выстрелил — задача тестируется в боевых условиях.
Физически это папка на сервере, в которую скачивается ветка репозитория и настраивается nginx; имеет собственный домен первого уровня — .
shot. На этом этапе генерируются переводы на основные языки.
Постановка — релиз тестируется в боевых условиях, переведен на все языки и полностью контролируется.
Все задания перепроверяются.
Если что-то не так с проблемой в релизе, мы откатываем ветку с ней с помощью git rebase. Эта функция используется не просто так: revert нам не подходит, так как после отката релизная ветка сольётся с основной, и из неё постоянно обновляются ветки с задачами.
В результате, когда разработчик проблемной задачи обновит свою ветку, его код исчезнет, и ему придется вернуться к коммиту.
возвращаться .
AIDA и Git
Из-за большого количества веток в описанной выше модели возникает множество задач по объединению веток, созданию релиза и мониторингу кода.Давайте посмотрим на их автоматическое решение:
Прежде всего, AIDA создает ветку сборки.Он прослушивает главную ветку, и если предыдущая ветка выпуска объединяется с основной, создается новая ветка.
Затем каждую минуту ветки с уже выполненными, протестированными и соответствующими шаблону в JIRA задачами объединяются в новую релизную ветку.
Если во время слияния возникает конфликт, разработчик и релиз-инженер получают об этом уведомление, а задача перенаправляется разработчику.
Поскольку основная ветка — это копия кода, развернутого на производственных серверах, и в нее добавляются изменения, ее необходимо постоянно объединять с релизной веткой.
AIDA выполняет это слияние, если в основной ветке зафиксировано изменение.
При возникновении конфликта появляется соответствующее сообщение.
Если после слияния с веткой релиза разработчик добавит изменение в ветку задач, то этот коммит будет перехвачен и AIDA сообщит об этом.
АИДА и ДЖИРА
Мы используем JIRA для контроля разработки, генерации релизов и тестирования.Рабочий процесс во всех проектах полностью проработан и формализован.
В процессе разработки и тестирования часть работы в баг-трекере выполняет AIDA. По сути, он помогает нам перемещать задачи или отображает в них определенную информацию.
Вот некоторые примеры:
разработчик фиксирует изменения кода в центральном репозитории, статус заявки автоматически меняется с «Открыто» на «В работе»; если по заявке создается Выстрел (код выложен в отдельном боевом окружении), то статус задания автоматически меняется на В Выстреле; Заявка автоматически открывается повторно при откате задачи из ветки релиза; Если задача прошла процедуру code review и последует изменение в ветке, то тикет возвращается на проверку.Также помогает изменить статус задачи, если есть определенные решения:
Исправлено и развернуто в производстве — билет автоматически меняет статус на «В производстве» AIDA информирует нас обо всей своей активности по заданиям.Такая автоматизация значительно упрощает работу с документооборотом и исключает рутинные действия.
AIDA и TeamCity
При сборке и автоматическом развертывании в тестовой среде мы хотели полностью избавиться от рутинных действий, но нам приходилось вручную вводить изменяющиеся названия веток релизов в проектах CI-сервера.На данный момент TeamCity ловит изменения во всех ветках по заданной маске (в нашем случае это маска строить_* ) и запускает сборку.
К сожалению, есть одна проблема: мы не можем удалить ветку по умолчанию из конфигурации проекта, и если туда приходят изменения, мы просто игнорируем ее.
При этом ветка расширяется, а мы теряем ресурсы и время.
Мы очень надеемся, что разработчики CI-сервера в ближайшее время исправят эту проблему.
Ссылки на билеты:
Поддержка спецификации ветвей в правиле триггера VCS. Игнорировать ветку VCS по умолчанию, использовать только спецификации ветвей для отслеживания изменений.Посмотрим, что происходит со сборкой и автоматическим развертыванием:
- Проект в TeamCity настроен на ветки с маской строить_* .
- После изменений в ветке релиза запускается автоматическая сборка.
- В случае успеха запускается сценарий развертывания на тестовых серверах.
- С помощью быстрых дымовых тестов (мы используем простой завиток) проверяется тестовое окружение.
- Если тесты не пройдены, версия выпуска помечается как плохая, а выпуск откатывается к предыдущей (хорошей) версии выпуска.
Вся процедура занимает три минуты.
Тесты обнаруживают только фатальные ошибки.
В этом случае все юнит-, авто- и функциональные тесты запускаются параллельно.
Это было сделано для того, чтобы тестировщик мог как можно быстрее увидеть задачу в тестовой среде.
Полученные результаты
Давайте посмотрим, какие действия автоматизирует AIDA:- Работает с Git, создает ветки, объединяет их, предупреждает, если что-то пойдет не так.
- Взаимодействует с JIRA, автоматически меняет статусы и обновляет информацию в задачах.
- Помогает TeamCity запускать сценарии, тесты и развертывать их в тестовой среде.
- автоматическое применение патчей для Git из специального интерфейса сбора, мониторинга, учета и формализации патчей, с полным перечнем информации и автоматическим уведомлением;
- полностью автоматический перенос задач из ветки сборки для изменения статуса тикета в JIRA;
- автоматический запуск юнит-тестов для каждой ветки задачи в момент ее выполнения и после изменения статуса в баг-трекере с последующим отчетом в JIRA.
P.S Создайте себе хороших помощников, которые не подведут в трудную минуту! Теги: #badoo #badu #автоматизация тестирования #git #teamcity #Jira #непрерывная интеграция #разработка веб-сайтов #тестирование ИТ-систем
-
Ноутбук Hp Compaq-620 Wz294Ut
19 Oct, 24 -
Наса Объявляет Новый График Программы Arm
19 Oct, 24 -
Zimbra Против Microsoft Office 365
19 Oct, 24 -
История Улиц Ярости
19 Oct, 24
