Каждый день разработчики и тестировщики сталкиваются с рутиной, которая отнимает время и энергию. А ведь хочется заниматься более творческими задачами. К счастью, технологии сегодня позволяют автоматизировать многие рутинные процессы, что значительно экономит время и повышает эффективность работы. 

В этой статье я расскажу о неочевидных автоматизациях, которые сделали нашу жизнь проще, и покажу, как реализовать их. В большинстве случаев нужна только техническая учётка для баг-трекера или DevOps-платформы.

Я уже больше трёх лет занимаюсь мобильной разработкой и тестированием. Первое время любила всё делать ручками, но чем больше становилась команда и чем опытнее становилась я сама, тем очевиднее становилось, что если можно что-то автоматизировать и это недорого, то чаще всего стоит заняться ускорением процессов.

Чаще всего желание что-то автоматизировать появляется, если:

1. Часто делаешь что-то однотипное.

2. Необходимо быстрое реагирование.

3. Нужно исключить человеческий фактор.

Я не буду говорить о том, что есть, кажется, по умолчанию, например про сборку установочного пакета после коммита/мёрджа. Лучше рассмотрим неочевидные места для улучшения производительности.

Закрытие старых merge requests

Кому-то может показаться странным, что некоторые merge requests долго висят открытыми. Но тем не менее такое происходит. Кто-то создаёт merge request, ревью он не проходит, человек уходит в отпуск, задача переходит к кому-то другому, он делает свой merge request, первый становится неактуальным, и все про него забывают. 

Бывает и так, что merge request создаётся в драфте и так и не доходит до продакшена, а закрыть его забывают. При этом неактуальные merge requests висят в общем списке и отвлекают. А если у вас ещё и есть ограничение количества открытых merge requests (у нас когда-то оно было для ускорения процесса ревью), это может стать настоящей проблемой. Поэтому мы сделали скрипт, который закрывает всё, что последний раз менялось больше двух недель назад.

Сначала мы запрашиваем все merge requests проекта, которые не менялись больше 12 дней:

if datetime.strptime(mr.updated_at, '%Y-%m-%dT%H:%M:%S.%f%z').date() < date.today() - timedelta(days=12):

и отправляем пользователю уведомление о том, что завтра его merge request закроется.

Потом смотрим на merge requests, которые неактивны уже более 14 дней, и закрываем их:

if datetime.strptime(mr.updated_at, '%Y-%m-%dT%H:%M:%S.%f%z').date() < date.today() - timedelta(days=14):

	mr.state_event = 'close'

	mr.save()

Создание тикетов для написания тест-кейсов и автотестов

Для большинства наших фич мы пишем тест-кейсы и автотесты, поэтому каждый раз создавать вручную одинаковые задачи нам быстро надоело (а однажды мы забыли создать такую задачу и вышли без автотестов). Поэтому мы реализовали автоматизацию, которая в баг-трекере ищет фичи со статусом «После бэклога» и создаёт к ним задачи для тестировщиков, сразу появляющиеся на борде. Ещё у таких фич надо проставлять label, чтобы исключить их из поиска и не создавать тикеты снова.

JiraNewCreator().create_ticket(epic=epic,

                           	summ='Написать тест-кейсы на ' + JiraNewCreator().jira.issue(epic).fields.summary,

                           	desc='Написать тест-кейсы на разработанный функционал')

automation_ticket = JiraNewCreator().create_ticket(epic=epic,

                                               	summ='Написать автотесты на ' + JiraNewCreator().jira.issue(

                                                   	epic).fields.summary,

                                               	desc='Написать автотесты на разработанный функционал')
add_label_to_issue(epic, 'QA_tickets')

Оповещение службы поддержки пользователей о выходе новой версии приложения

Специалисты службы поддержки должны знать о том, что пользователи уже могут скачать новую версию, чтобы быть готовыми к вопросам, касающимся новых фич, и чтобы оповестить пользователей о том, что та или иная проблема из прошлой сборки была решена и можно обновить приложение. Чтобы не писать об этом после каждого релиза, мы сделали скрипт, который создаёт тикет и сообщает о запуске новой версии, а также о том, на какую долю пользователей она раскатана.

summ = 'Новая версия приложения ' + platform + pipeline_name

desc = 'Вышла новая версия приложения ' + platform + pipeline_name + '. Автоматическое обновление доступно для ' + percent + '% пользователей'

issue_dict = {

	'project': {'key': 'RANDOMSUPPORTPROJECT'},  # key for project

	'summary': summ,

	'description': desc,

	'issuetype': {'name': 'ТИП ТИКЕТА'},

	'customfield_11103' : {"value" : "Нужное вам значение","child": {"value":"с его параметром"}},

}

new_issue = self.jira.create_issue(fields=issue_dict)

Создание релизного тикета

Команде важно понимать скоуп релиза. Мы добавляем фичам параметр fix version, по которому ясно, в какой сборке они оказываются. Этот параметр мы также используем для формирования тикета, который содержит в себе все фичи, разделённые по направлениям, релиз-мастеров, ссылки на тестовые прогоны по релизу (которые тоже формирует этот скрипт). После формирования тикета ссылка на него публикуется в профильном  канале корпоративного мессенджера.

Ежедневные отчёты о состоянии релиза

Раньше мы каждый день заходили в систему сборки крэшей, чтобы посмотреть на метрики релиза и оценить его качество. Теперь мы каждое утро получаем отчёт о его состоянии. Это немного сложнее, чем может показаться, поскольку надо понимать, какой релиз в проде в данный момент, и собирать именно его метрики. Мы реализовали это через таск-трекер, в котором отмечается последний выпущенный релиз. Получив его, формируем ссылку в Grafana и забираем оттуда данные.

Назначать ревьюеров для merge requests

Изучение чужого кода далеко не всегда является увлекательным занятием. Обычно просто кто-то из команды должен зайти и посмотреть. Но, как известно, от общей ответственности недалеко до общей безответственности. Поэтому мы назначаем ревьюеров для merge requests: одного — из команды, которая создала merge request, и одного — из любой другой команды. Для этого мы собрали списки участников команд и, когда создаётся merge request, случайным образом выбираем из двух списков сотрудников для ревью. 

rand_teammate = random.choice(teammates).replace(.ru", "", 1)

rand_teammate_id = self.conn.connect_by_approver.users.list(username=f'{rand_teammate}')[0].attributes['id']

reviewers_ids.append(rand_teammate_id)

Standup bot

И напоследок самая простая, но очень удобная автоматизация. Во времена удалёнки и Slack многие привыкли к Standup bot, который отправляет сообщение в канал с призывом написать, что было или будет сделано. Это хорошая альтернатива ежедневным созвонам для некоторых команд. Но Slack мы лишились, а в Chatzone (наш аналог Slack), на который мы перешли, такого бота не было. Поэтому мы сами реализовали отправку сообщения в нужный канал в определённое время. Суперпростая автоматизация, в которой ты просто отправляешь строчку.

Заключение

Это небольшая часть автоматизаций, которые у нас есть. Ещё мы делаем алерты (как персональные, так и командные), создаём онбординг-задачи для новичков, автоматически вливаем фичи в дев после тестирования и, наоборот, подливаем дев в фичи перед тестированием, удаляем старые ветки и многое другое. 

Благодаря всем этим фичам у нас остаётся больше времени на разработку и тестирование и иногда даже складывается ощущение, что процесс идёт сам по себе. 

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