Экспресс до стора: как мы запускали релизный поезд

Всем привет! Меня зовут Николай, я тимлид android-команды СберМегаМаркета. Сегодня расскажу вам, как мы меняли релизный процесс в компании.

С чего все начиналось

Когда мы начинали разработку android-приложения нашего маркетплейса, процесс релиза выглядел очень просто: разработчик работал по стандартному gitflow, создавал Merge request. Когда задача попадала в релиз, тимлид команды вливал Merge request в релизную ветку и отправлял релиз в тестирование. После успешной проверки всех задач релиз публиковался в сторе.

С этим процессом был связан ряд сложностей:

1. Большое количество доработок, реализуемых в уже сделанных задачах. Требования по ним приходилось уточнять у коллег продакт-менеджеров.

2. Срочные задачи от стейкхолдеров, маркетинга и бизнеса не могли выкатываться отдельно от уже собранного релиза, поэтому, попадая в релиз, они увеличивали время на весь релиз.

3. Merge requests не вливались сразу после аппрува, а вливались только в момент, когда мы понимали, что пора собирать релиз. Таким образом, при каждом релизе мы порождали конфликтующие изменения во всех Merge request.

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

Шаг 1: Тестирование задач в feature-ветках

Чтобы решить проблему с задачами, для которых надо было уточнять требования, мы решили отказаться от проверки релиза со всеми задачами за один раз. Предложили стейкхолдерам и бизнесу новый способ тестирования задач и новый процесс релиза. Это не стало неожиданностью для бизнеса, так как такая схема уже работала на бекенде, а мы только адаптировали ее под свои нужды.

Мы разделили процесс релиза на две части:

1. проверка задачи в отдельном мини-релизе;

2. проверка всех задач, которые прошли первое тестирование, в одном релизе.

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

Здесь мы задумались о том, как доставлять feature-билд до QA. Это не релизный билд, который собирается раз в неделю и отправляется в тестирование, а один билд на задачу. В разработке их может быть много, и собирать такие билды будут часто.

Для доставки билдов решили переехать с Firebase App Distributor на собственное решение. В СберМегаМаркет для хранения артефактов билдов и файлов в основном используется minio, так что решили использовать его.

Когда DevOps сделали бакет в minio, мы начали настраивать загрузку через CI/CD и завели в нем отдельный build step для загрузки feature-билд:

deploy task for feature test:
  stage: deploy
  tags:
    - android
  artifacts:
    paths:
      - goods/outputs/
    expire_in: 3 mos
  needs:
    - job: check that jira task can be moved to desired state
  script:
    - echo [DEPLOY FOR FEATURE TEST] STARTED
    - ./gradlew assembleApiTestRelease assembleApiProdRelease --stacktrace -PFeatureVersion=
    - mv ./app/build/outputs/apk/*/release/*.apk ./outputs    
    - cd outputs    
    - echo [DEPLOY FOR FEATURE TEST]
    - date=" class="formula inline">( date +'%d%m%Y_%I%M%S' )   
    - folder="minio/mobile-app-user-prod/QA/Feature/{date}"
    - mc mb -p   
    - echo [DEPLOY FOR FEATURE TEST] Uploading test build
    - mc cp * $folder  
    - echo [DEPLOY FOR FEATURE TEST] FINISHED
  rules:    
    - if: '" class="formula inline">CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^develop/    
    when: on_success 
  allow_failure: true
  interruptible: true

После всех настроек встал вопрос: как QA будет скачивать и искать билды в S3 хранилище. Для этого написали простое приложение, состоящее из одного экрана и поля для поиска.

Еще одной сложностью стала нумерация версий. Релизу нужно было присвоить такую версию, чтобы QA могли устанавливать приложение поверх ранее установленных без удаления. Тут было намного проще, так как номер релизной версии – это 8 цифр. Он выглядит так: 

Для версии feature-билд мы решили использовать номер задачи из Jira, который всегда есть в названии git-ветки. Алгоритм генерации простой: берем номер задачи, дополняем число до 8 цифр и отказываемся от инкремента последних двух цифр:

Вся эта подготовка и запуск нового процесса релиза принесли пользу:

• Более качественные фичи стали попадать в билд с минимальным количеством багов.

• Уточнение требований у продакт-менеджеров никак не влияет на релизный билд, а происходит на этапе проверки feature-билд.

• Срок проверки билда уменьшился с 2–3 до 1 недели.

• Благодаря возможности повышения приоритета у задачи при проверке в ветках стало проще выпускать срочные задачи.

Шаг 2: Запускаем скоростной релизный поезд

Несмотря на все нововведения, у нас осталась пара нерешенных моментов:

• Релизный цикл не зафиксировался и варьировался от недели до полутора недель.

• Merge request так и не вливались после аппрува.

С ними решили справляться уже при помощи точечных изменений в рабочих процессах. Прежде всего, мы зафиксировали релизный цикл на двух неделях. Это дало стейкхолдерам понимание того, когда новый релизный билд отправляется на тестирование. Затем выдали разработчикам права на мердж своих Merge request в develop-ветку (раньше этим занимался team lead). Наконец, был написал манифест по релизному поезду:

Политика разработки мобильного приложения СММ:

• Разработка каждой задачи ведется в feature-ветке согласно git flow.

• Задача передается в тестирование при ее готовности, для передачи задачи в тест необходимо: добавить комментарий к задаче в jira, содержащий ссылку на PR, в рамках которого была осуществлена разработка задачи, краткое описание проделанной работы и возможный импакт на части платформы/приложения, если те были затронуты в рамках выполнения задачи, перевести задачу в соответствующий статус. Также в комментарии необходимо указать feature-toggle, ab-test (если такие имеются), необходимые для тестирования задачи.

• Задачи тестируются на feature-ветках, сборка feature-версии приложения находится в зоне ответственности ведущего задачу разработчика.

• При обнаружении багов в разработанных задачах, задача переводится в REDO, и тестирование уведомляет ответственного разработчика о том, что задача не может быть влита в master-/develop-ветку.

• После аппрува от тестирования есть ttm = 1 день, за который задача должна быть влита в master-/develop-ветку приложения, при внесении изменений после тестирования необходимо передать тестированию информацию о возможных изменениях функциональности и составить импакт-анализ.

• Для поддержания актуального состояния веток – после критических изменений в master-/develop-ветках разработчикам необходимо проделать rebase feature-ветки от целевой ветки.

• ttm = 2 дня, для того, чтобы задача была в Review.

Релизы мобильного приложения СММ:

• Релизы осуществляются раз в 2 недели с разницей в 1 неделю между платформами.

• В пятницу каждой календарной недели осуществляется FF (Feature freeze текущей версии приложения), срезается ветка release/* – после этого релиз считается готовым к регрессионному тестированию, и остальные задачи не могут попасть в релиз. Исключение – краши приложений или специальное распоряжение руководителя отдела/руководителя направления.

• В понедельник мобильные разработчики соответствующей платформы просматривают все PR, попавшие в релиз, и составляют импакт анализ – комментарий к задаче в jira с информацией о том, что могло сломаться или что стоит дополнительно проверить в рамках регресса в текущем релизе. Тестирование осуществляет регрессионное тестирование релиза.

• В случае обнаружения багов в процессе регрессионного тестирования, тестированием создается соответствующая задача в jira и назначается на ответственного разработчика/продакта. Ветка git для починки бага создается отсоединением от release/* ветки приложения.

• После успешного выполнения регрессионного тестирования и починки найденных багов осуществляется отправка приложения в каналы дистрибуции приложения. Также производится влитие релизной ветки в основную.

Этот манифест был обговорен с разработкой и в течение 2 недель запустился в команде. 

В результате релизный цикл действительно стабилизировался, а конфликты Merge request сократились, но, увы, не пропали полностью. Зачастую разработчики забывают сливать ветки в develop проверенные Merge request, несвоевременно отправляют feature-билд в QA. Так что мы запустили инициативу по написанию бота, который будет оповещать разработчика о том, что надо слить Merge request в develop и отправить feature-билд в тестирование.

Также не удалось полностью избавиться от сложностей со срочными задачами и задачами со сроками. Порой все же приходится жонглировать релизами для выпуска таких задач. Мы пока не придумали хорошего решения, но продолжаем поиски.