🔥

Тред (Осип Фаткуллин)


Кстати, лайкайте этот твит, если интересно про автоматизации. Могу раскрыть эту тему подробнее, может и тред отдельный сделаю.
Что-ж. Как обещал, попробую сделать тред про автоматизации. twitter.com/mobileunderhoo…

Когда-нибудь, когда у меня будет свой дом, я займусь автоматизациями в нём, а пока довольствуюсь автоматизацией flow работы.

Для меня в рабочем процессе есть две вещи, которые хочется максимально оптимизировать и автоматизировать. - Работа с треккером задач (у нас это Jira) - Код-ревью

Флоу работы с Jira у нас выглядит примерно так: - TODO - In Progress - Review - Resolved (задача вошла в релиз) - Done (задача протестирована и закрыта)

Почти всё дальше будет про JIRA, но некоторые общие подходы можно применить и с другими треккерами.

В In Progress хочется переводить в тот же момент когда создаёшь ветку для работы над задачей. В IDEA это можно сделать через плагин Task Management, а если такой вариант не подходит, можно использовать Raycast raycast.com

В ревью нужно переводить задачу в тот момент когда создан MR с ней. Тут я знаю два варианта: - На CI смотреть номера задач внутри MRa и через апишку менять им статус - Включить интеграцию Jira c GitLab/GitHub

В случае GitLab, интеграция с Jira есть прямо в настройках проекта. Там нужно указать креды для входа и адрес Jira, после чего все номера issue станут кликабельными, а при упоминании их в MR'ах в Jira будет добавляться комментарий об этом.

Это самая простая интеграция, есть более сложная, которая позволяет использовать разные триггеры и действия в Jira Automations.

Jira Automations это no-code конструктор автоматизаций. Сделан очень неплохо, позволяет даже переменные определять, ходить по циклам и всякое такое. Есть большое количество триггеров и действий, если чего-то не хватает можно самому дописать.

В нашем случае, к сожалению, не получилось подключить полноценную интеграцию, есть только базовая. Поэтому дальше буду показывать наши костыли :D

Базовая интеграция умеет оставлять комментарии если упомянуть issue в MRе, это и используем как триггер, чтобы перевести задачу в Code Review
notion image

Если бы интеграция была полноценная, костылить не пришлось и нужно было бы просто выбрать нужный триггер
notion image

Перевод Code Review работает, теперь нужно переводить в Resolved когда MR влит. Благо, что это умеет делать базовая интеграция в GitLab, но были случаи когда просто писали скрипт на CI, который закрывал все упомянутые в MR задачи при вливе.
notion image

Важно, что в GitLab автоматическое закрытие задач работает только если вы вливаете свою ветку в основную ветку проекта.

Но есть ещё проблема. После перевода задачи в Resolved нужно ведь ещё и Fix version указать, иначе задача потеряется и не попадёт в release notes. Тут снова помогают Automations. При переводе задачи в resolved автоматически проставляем ей ближайшую не выпущенную версию
notion image
notion image

Вся сложность в том как вычисляется значение {{nextVersion}}. Оно вычисляется с помощью Smart Values и выглядит это довольно страшно. Тут мы проходимся по всем версиям в проекте, достаём только те которые не выпущены и начинаются с буквы "a" (a - for Android) и берём последнюю
notion image

Отлично, перевод в Resolved тоже есть, версия проставляется, а дальше уже дело за QA.

Теперь хочется чтобы при закрытии версии, создавалась новая. Версия состоит из имени и кода и выглядит так: a1.0(42) Для простоты с именем ничего делать не будем, считаем, что меняется оно редко и раз в месяц можно и руками поменять. А вот номер должен всё время увеличиваться.

Опять идём в Automations и набрасываем автоматизацию на закрытие версии. Вся работа по инкременту происходит внутри объявления переменных, их содержимое в следующем твите.
notion image

Регулярками выкусываем нужные значения, а в конце составляем новую версию, но инкрементируем versionCode
notion image
notion image
notion image

Выпускать версию можно автоматически когда CI делает сборку. В качестве CD мы используем fastlane, поэтому эту задачу решаем через него плагинами jira_versions и jira_release_notes.

Ещё одно неудобство - чтобы всё работало как нужно, мы должны упоминать задачки в описании MRа. Если задач больше чем одна, руками это делать лениво. Тут помогает Danger на CI. Проходит по комментариям к коммитам, достаёт все номера issue и добавляет их в описание MRа.

В итоге получаем автоматизированный флоу, где от разработчика требуется: - Дать пинок - перевести задачу в In Progress - В коммитах указывать номер задачи А всё остальное сделают автоматизации.

Как можно оптимизировать ревью? Для меня это пока не решенная задача, если накидаете идей, буду благодарен. Хочется проводить ревью внутри IDE, чтобы иметь возможность посмотреть что где используется

Возможно в XCode ситуация другая, но в IDEA если у вас GitHub или Space - всё замечательно, есть официальные плагины которые показывают все PRы и позволяют быстро их спуллить, поревьюить и оставлять комментарии прямо из IDE. А вот с GitLab приходится мучиться.

Есть плагин Merge Request Integration - Code Review for GitLab, но у меня он работал очень нестабильно. Ещё пробовал CodeStream - тоже не без проблем, но ребята достаточно быстро реагируют на баги заведённые на GitHub.

Ещё в CodeStream есть возможность делать "быстрые ревью". Это когда ты посреди работы над фичой можешь выделить кусок кода и запросить ревью. А другому разработчику внутри IDE выскочит уведомление об этом.

Из дополнительных приятностей: Можно оставлять комментарии к коду, прокидывая их сразу в Slack (и не только). Можно открывать, закрывать и проводить по статусам issue из Jira (и не только). Если бы не редкие косяки с отображением комментариев в MRах, цены бы не было.

Как-то так. Хотел сделать тред про автоматизации, но вышло в основном про "наш процесс" :)

Осип ФаткуллинОсип Фаткуллин