Больше, лучше, быстрее: как мы автоматизировали релизы Metabase

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

Я начал в эпоху ручного труда

Когда меня впервые назначили ответственным за релизы в 2022 году, выпуск Metabase включал в себя выполнение длинного и сложного контрольного списка: собрать бинарный файл на локальной машине разработчика, провести ручное тестирование кликами для проверки целостности файла, запустить несколько скриптов для контейнеризации и, наконец, загрузить всё это в Docker Hub и на наш сайт. Это был не самый ужасный процесс, особенно учитывая, что мы выпускали новую минорную версию Metabase раз в две недели (или реже), а новую мажорную — раз в три-четыре месяца.

Я понимал, что мы можем работать лучше, по нескольким причинам:

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

Превращение контрольного списка в GitHub Actions

Это потребовало преобразования мешанины из Bash и Clojure скриптов в более связный (и протестированный) набор функций на TypeScript.

Первоначальный проект процесса состоял из трех независимых рабочих процессов:

• Сборка
• Тестирование
• Публикация

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

Повторное использование протестированных сборок

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

• Сборка + тестирование
• Публикация

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

• Присвоение версии + тестирование
• Публикация

По мере того как мы обретали уверенность в этом рабочем процессе, и он превратился в простое выполнение пары команд GitHub Actions, мы перешли от релизов раз в две недели к еженедельным. Мы часто выпускали минорные версии для нескольких мажорных версий Metabase каждую неделю (например, v61.2 и v60.9).

Пусть релизы работают сами

По мере того как мы привыкали выпускать обновления быстрее, наша команда по работе с клиентами была особенно в восторге от нашей способности быстрее доставлять исправления ошибок конкретным пользователям, и даже еженедельный график начал казаться излишне медленным. Почему бы нам не доставлять исправления ошибок пользователям как можно быстрее? Поэтому, начиная с August 2024, мы начали выпускать патчи каждый будний день.

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

• Присвоение версии + тестирование + публикация

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

Релизы в три клика, в стиле Windows 95

Раз всё движется так быстро, почему бы не выпускать обновления по требованию, когда у нас есть изменения для Metabase Cloud или когда клиенту нужно срочное исправление? Поэтому мы создали интерфейс в нашей внутренней системе CI, который делает выпуск новой версии Metabase делом буквально трех кликов.

Тема Windows 95 сделала это еще быстрее.

Оказывается, лень, применяемая последовательно в течение нескольких лет, очень похожа на непрерывную доставку (continuous delivery).

Вам не нужно обновлять Metabase каждый день, но если вы ждете исправления, вы можете получить его в тот же день, когда оно было готово, а не через две недели. Если вы используете Metabase Cloud, вы получаете его автоматически. Если вы используете self-hosted версию, забирайте патч, когда он вам понадобится, или оставайтесь на текущей версии, пока не будете готовы.

• Знакомьтесь, Repro-Bot — наш агент по сортировке задач в GitHub
• Как мы создали десять пользовательских субагентов для управления кодовой базой Clojure на 500 тысяч строк
• Улучшение производительности популярного инструмента разработки на Clojure — clojure-lsp
• Как мы выбрали LibreChat — и в итоге получили агента для Slack

И если вам интересно помочь нам в непрерывной доставке, мы всегда нанимаем сотрудников.