Всем привет! Меня зовут Дмитрий, я релиз-инженер вкоманде CI/CD Speed Авито. Вот уже несколько лет мы сколлегами отвечаем за всё, что связано срелизами наших мобильных приложений и не только. Пронаши релизные поезда и как мы кэтому шли уже очень подробно рассказывал Алексей Шпирко.
Но мы не стоим наместе и сегодня постараемся рассказать, как наша система CI/CD эволюционировала изнабора скриптов и TeamCity-билдов вполноценный сервис мобильных релизов, позволяющий управлять всем процессом выпуска приложений черезудобный интерфейс.
Немного контекста
Мобильное приложение Авито это:
- Десятки продуктовых команд.
- 20+ разработчиков на каждую изплатформ.
- Тысячи UI-тестов.
- Десятки тысяч UNIT-тестов.
- Сотни тысяч строк кода.
- Еженедельные релизы Android.
- Релизы iOS раз вдвенедели.
Процесс релиза состоит изследующий частей:
- Срез релизной ветки изdevelop и простановка тега вgit.
- Прогон всех автоматических проверок кода и прогон всех видов тестов.
- Сборка релиз-кандидата.
- Загрузка релиз-кандидата вAppStore/GooglePlay и внутреннее хранилище артефактов.
- Отправка необходимой информации всистемы мониторинга.
- Загрузка данных всистему управления фича-тоглами.
- Сборка what's new дляQA и редакторов.
- Подготовка Jira-артефактов простановка версии в задачи, создание задач дляредакторов, QA и релиз-инженеров.
- Нотификация всех заинтересованных лиц оготовности релиз-кандидата.
- Регрессионное тестирование.
- Выпуск приложения начасть пользователей и нотификация обэтом.
- Выпуск приложения на100% пользователей и снова нотификация.
Так устроен наш релизный поезд
В начале 2019года всё это успешно обслуживалось несколькими десяткам скриптов наразных языках и сложными цепочками TeamCity-билдов. Каждое воскресенье cron запускал стартовую TeamCity-конфигурацию, скрипты и билды выполняли всю работу изпунктов 1-9.
Если всё шло хорошо, продуктовые команды разбирали результаты автотестирования и что-то допроверяли руками. Редакторы писали красивые тексты, а релиз-инженеры следили запервыми и вторыми и ждали, когда можно будет нажать назаветную кнопку релиз вмаркете. Идиллия и победа автоматизации надрутинным трудом.
Но вкажущемся благополучии таился ряд проблем.
Проблема 1. Сложные цепочки билдов вTeamCity
Релизный процесс состоит измногих этапов. Каждый следующий этап зависит отпредыдущего или нескольких предыдущих. И ковсему этому добавляется множество внешних систем.
Организация подобной системы набазе TeamCity отлично работает и выполняет поставленную задачу, но привозрастающей сложности и скорости вы неизбежно сталкиваетесь срядом проблем:
- Много билдов и сложные связи между ними.
- Сложность поддержки и внесения изменений.
- Сложность тестирования всего процесса или его частей.
- Сложно или нельзя запустить процесс начиная сточки отказа.
Например билд-1 завершает работу, билд-3 ждёт результаты выполнения билдов 1 и 4, а вбилде-7 поменяли параметр, и вся система черезчас работы рухнула. Садишься, разбираешься что куда нужно пробросить и кому что скормить или перезапускаешь весь процесс снуля. В итоге теряешь много сил и времени и получаешь временами автоматизацию наручном приводе.
Это усугублялось другой проблемой или же особенностью организации нашей работы.
Проблема 2. Зоны ответственности
Так сложилось, что наша большая команда состоит издвух независимых команд поменьше. Это собственно мы CI/CD team и наши коллеги Testing team. Мы отвечаем завсю общую часть релиза или же CD как взять нужный срез кода и донести его пользователям. Ребята изTesting team отвечают завсю платформа-специфичную часть как собрать приложение, прогнать нанём нужные тесты и отдать это нам.
И, соответственно, релизная цепочка билдов содержала как наши билды (срез ветки, Jira-задачи, оповещалки, подготовку артефактов дляручных проверок) так и билды коллег. Билды зависели друг отдруга, и это мешало быстро развивать как наши системы и процессы, так и системы и процессы ребят, потому что любое косвенное изменение потенциально ломало весь процесс.
Частично эту проблему мы постарались решить спомощью ночных тестовых релизов. Каждую ночь весь процесс запускался натестовых данных, и утром мы могли видеть состояние системы. Но была ещё одна проблема.
Проблема 3. Люди
У нас есть часть релизного процесса, вкоторой участвуют люди. Это непосредственные участники: тестировщики, редакторы, релиз-инженеры. И косвенные, но заинтересованные втом, чтобы пользователи получили приложение: продакт-менеджеры, разработчики, маркетологи, аналитики. Раньше вся коммуникация осуществлялась через Slack-каналы, а актуальное состояние релиза было разбросано поразным местам (Jira, Slack), его знал только релиз-инженер. Поэтому ему приходилось тратить много времени отвечая навопросы когда поедем на 100%?, релиз стартанул?, так уже можно тестировать или нет?, а следующий релиз когда?.
Настало время подойти квопросу не эволюционно, а революционно, и решить все проблемы разом, взяв лучшее, что у нас есть.
Разграничиваем ответственность
Как уже говорилось, наша большая команда состоит издвух команд поменьше, каждая изкоторых отвечает заCI или CD часть всего процесса.
Давайте посмотрим, что мы вкладываем вэти понятия.
CD:
- срез релизной ветки вgit;
- простановка тегов вgit;
- запуск CI-части;
- подготовка релизных артефактов (Jira-задачи, Release Notes);
- подготовка регрессионных артефактов;
- оповещения остадиях релиза;
- релиз.
CI:
- прогон всех тестов;
- сборка приложения;
- сборка платформ-специфических артефактов;
- загрузка приложения вмаркет.
Видно, что есть разграничение зон ответственности напроцессном уровне и есть четкое разграничение наорганизационном уровне. Но вобщем релизном процессе науровне TeamCity всё перемешивалось и доставляло очень много проблем.
При этом, в большинстве своём, CI ничего не знает проCD. CD запускает CI-часть стребуемыми параметрами и ждёт завершения билдов, чтобы получить изних необходимые артефакты. Получается, что жёсткая связность между билдами и сложные зависимости многие-ко-многим были не оправданы. Мы решили явно разграничить CI и CD, сделать одну точку взаимодействия между ними и связать её контрактом.
Контракт по своей сути это пара JSON-файлов, один изкоторых CD передаёт вCI-часть, а второй ожидается как результат работы CI.
CD вэтой концепции является менеджером процесса, он полностью управляет релизом, конфигурирует CI и ожидает определённых результатов его работы. CI же просто выполняет работу, которую заказывает CD. Обе части могут существовать и разрабатываться абсолютно автономно приусловии соблюдения контракта.
Пример входного файла контракта config.json:
{"schema_version": 1, "project": "avito", "release_version": "777.5", "output_descriptor": { "path":"http://artifactory.ru/releases/avito_android/777.5_1/output.json", "skip_upload": false}, "deployments": [ { "type": "google-play", "artifact_type": "bundle", "build_variant": "release", "track": "beta" } ]}
Тут мы сообщаем CI-части, что хотим собрать релиз проекта Авито сномером 777.5, ожидаем, что выходной файл врезультате работы будет загружен попути, описанному вoutput_descriptor, а также заказываем, какие артефакты и вкаком виде должны быть собраны и куда загружены после.
Пример выходного файла контракта output.json:
{ "schema_version": 1, "teamcity_build_url": "https://tmct.ru/viewLog.html?buildId=17317583", "build_number": "777", "release_version": "777.5", "git_branch": { "name": "release-avito/777.5", "commit_hash": "2c54c50c220bf91bc1a6ca10b34f53a540c80551" }, "test_results": { "report_id": "5f3e94fd23d67bf434e5c1b8", "report_url": "https://tests.avito.ru/report/AvitoAndroid/FunctionalTests/2c54c50c220bf91", "report_coordinates": { "plan_slug": "AvitoAndroid", "job_slug": "FunctionalTests", "run_id": "2c54c50c220bf91" } }, "artifacts": [ { "type": "apk", "name": "avito-777.5-777-release.apk", "uri": "http://example.com/artifactory/android/avito/777.5-777/avito-777.5-777-release.apk", "build_variant": "release" }, ]}
В нём содержатся результаты выполнения работы CI и все значимые длядальнейшего процесса данные вроде ссылок наартефакты и результатов тестов.
Nupokati: сервис релизов мобильных приложений
Благодаря контракту нам удалось решить проблему жёсткой связности и сложных зависимостей междуразными частями релизного поезда. Но это не решало проблемы прозрачности, поддерживаемости и управляемости всего процесса. У нас всё ещё оставались клубки изтимсити-билдов нанашей стороне поезда.
Поэтому мы решили отказаться отTeamCity вCD и реализовывать собственный сервис релизов мобильных приложений.
Что мы хотели получить отнового сервиса?
- Отсутствие сложных связей и неявных зависимостей.
- Перезапуск релиза, начиная сточки отказа.
- Прозрачность процесса релизов длявсех участников.
- Простую поддержку, кастомизацию и тестирование.
- Возможность использования наразных мобильных проектах компании.
Так появился сервис мобильных релизов Nupokati рабочее название прижилось и осталось снами.
Он состоит изуправляющего CD-сервиса наPython и дашборда
мобильных релизов.
Покрону CD-сервис проверяет календарь релизов и стартует нужный
релиз, запускает CI, выполняет все необходимые взаимодействия
свнешними сервисами и извещает всех заинтересованных участников
процесса окаждой стадии.
Основная управляющая сущность вCD-сервисе это
Release.
Он, как конструктор, собирается из различных шагов:
Вот пример небольшой части релиза:
Это позволяет нам сохранять модульность и гибкость и быстро подключать новые проекты ксервису, просто набирая нужный pipeline изшагов. Приэтом каждый релиз имеет явный стейт, который позволяет перезапускать релиз слюбой точки релизного поезда и получать предсказуемый результат.
Дашборд же служит панелью управления всем процессом и показывает актуальное состояние конкретного релиза:
Здесь есть вся необходимая информация порелизу и ссылки
наартефакты
Также отсюда осуществляется всё управление релизом
И отображается актуальное положение релизного поезда
Помимо этого надашборде можно всегда найти информацию опрошлых
релизах и календарь спланируемыми
Итоги
Такая простая напервый взгляд вещь как контракт между CI и CD оказалась длянас революционной и позволила получить удобную дляразработки, поддержки и использования систему релизов мобильных приложений. Контракт позволил нам вылечить все проблемы и не прибавить впроцессе новых.
Нужно понимать, что подход влюбой непонятной ситуации пили свой велосипед не является универсальным, и любую проблему можно решить разными путями. Но внашем случае свой велосипед и время наего разработку окупились черезудобство использования, поддержки и сотни сэкономленных человеко-часов. Он просто работает и выполняет свою функцию, радуя всех участников релизного процесса.
