Как наша команда Delivery, используя только собственные ресурсы, переделала нашу систему под CI/CD.

Команды инженеров постоянно испытывают давление: нужно выдавать новые функции в виде достойного продукта и при этом постоянно минимизировать время цикла. Зачастую специалисты не думая хватаются за современный инструментарий. Непрерывная интеграция и поставка (CI/CD) встроены в GitLab, наше единственное приложение для жизненного цикла DevOps, и сейчас мы, чтобы еще больше сократить время цикла, всем составом мигрируем на Kubernetes. Однако к CI/CD — и в конечном итоге Kubernetes — мы шли не совсем обычным путем. Команда Delivery, переводя нас на непрерывную поставку GitLab.com, напрягла старую систему, и только потом мы полностью перешли на Kubernetes.

Как мы выпускали релизы до CI/CD

В период с 7 августа по 27 сентября 2019 года огромное сообщество GitLab и члены нашей команды достигли уровня в среднем 55 коммитов в день — это непрерывные итерации нашего продукта для создания новых функции. Но прежде чем мы освоили непрерывную поставку, мы использовали периоды заморозки новых функций, начинавшиеся 7 числа каждого месяца: в это время наши инженеры переключали внимание с разработки новых функций на отладку в подготовку грядущих релизов, выходящих стабильно 22 числа, ежемесячно.

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

"… разработчики начали плясать от даты "7-ое", потому что смотрели на календарь и думали: ну, время еще есть, 7 число через неделю, — а потом, в полночь 6-го принимались судорожно осуществлять слияния", — сказал Марин Янковски, технический директор команды Delivery. — "Они знают: если сорвут сроки, придется ждать еще месяц, а если успеют ко времени, у них будет еще добрых две недели на отладку".

С самого зарождения GitLab.com, периоды заморозки новых функций использовались как время для стабилизации, — пояснил Марин.

Однако число пользователей росло и потребность в новых функциях заставляла нас ускорять темпы разработки. Период стабилизации тормозил цикл и сильно задерживал переход к отладке, регрессии и поставке функций — как пользователям на Gitlab.com, так и индивидуальным клиентам.

"В некоторых случаях [заморозки новых функций] провоцировали даже нестабильность платформы — ввиду того, что починки высшего приоритета не доходили до клиента вовремя", — сказал Марин. — "Перейдя на CI/CD, мы выдаем новинки и отлаживаем их куда быстрее".

До того, как мы сформировали команду Delivery для перевода GitLab.com на непрерывную поставку, — и в конце концов на Kubernetes — мы зависели от релиз-менеджера. Это была переходящая в среде разработчиков должность, которую занимал тот, кто готовил новый выпуск. Мы больше 5 лет производили итерации процесса, но вот релиз-менеджеры создали базу знаний и более-менее автоматизировали его.

Однако метод оказался неэффективен, потому что расписание развертываний и подготовки к выпускам плавало: от половины дня до нескольких дней — из-за того, что в процессе накапливались задания для ручного исполнения.

"Релиз-менеджер получал фиксированный список задач, крайний срок выполнения и повторял перечисленные шаги снова и снова, пока не получался полностью готовый и стабильный выпуск на GitLab.com", — пояснил Марин. В самом обобщенном смысле, сделать от релиз-менеджера требовалось вот что:

Вручную синхронизировать множество репозиториев, из которых состоит GitLab.
Убедиться, что в созданных вручную ветках Git включены корректные версии.
Когда выпуск получит метки, вручную развернуть в GitLab.com тестовую и производственную среды.
Убедиться, что все работает, и вручную опубликовать пакеты для индивидуальных пользователей.

На презентации в Бруклине во время GitLab Commit, посвященной этой теме, Марин поделился результатами наблюдений за 2018 год: в двухнедельный период до релиза команда Delivery тратила 60% времени, сюсюкаясь с развертываниями, еще 26% — на ручное и полуручное выполнение задач вроде написания обзора ежемесячного выпуска.

Результаты наблюдений за 2018 год, до перехода на непрерывную поставку: вот как команда Delivery расходовала время за 2 недели до релиза.

"Если говорить в общем, то за 14 дней, за две недели до релиза команда только и делала, что пялилась в мониторы, глядя, как сохнет краска, что ли", — сказал Марин.

Но взявшись за 86% этого пирога (60% на развертывания + 26% на ручное выполнение задач), команда Delivery решила бы ряд проблем:

Новые выпуски без задержек.
Повторяемые и более быстрые развертывания без даунтаймов.
Больше времени на миграцию GitLab.com на Kubernetes.
Больше свободы для подготовки организации к непрерывной поставке.

И хотя CD доступна только на GitLab.com, наши индивидуальные клиенты тоже получают выгоду от нашего перехода на нее. Теперь все, что не затронуто проверкой CI, тестируется автоматически и вручную в средах — прежде чем попасть на GitLab.com. Все, что попадает на GitLab.com и нуждается в отладке, будет отлажено в течение нескольких часов. Так что окончательный выпуск для индивидуальных клиентов будет чист.

Переход от периодов заморозки к CD был вопросом времени, поскольку рос наш стек функций, и появилась команда инженеров под управлением Марина — для наблюдения за переходом: "Команда Delivery была сформирована с единственной целью — перевести компанию на модель CD, а заодно — для перевода компании на платформу Kubernetes, чтобы облегчить масштабирование и ускорить цикл".

Большинство компаний на месте GitLab начали бы переход на CI/CD и Kubernetes, сперва интегрировав в свой рабочий процесс новые технологии и исправив по ходу процесс разработки. Мы же выбрали иной подход.

Миграция на Kubernetes требует перемены не только в производственной системе, но и в подходе к разработке, — пояснил Марин. Kubernetes предлагает определенные функции, доступные легко и без дополнительных вложений. Но для того, чтобы извлечь реальную пользу из бесплатных возможностей, предлагаемых Kubernetes, нужна какая-никакая CI/CD.

Команда Delivery приняла это: в целях облегчения перехода на Kubernetes для непрерывной поставки наши инженеры уже должны работать с прицелом на CI/CD, а это подразумевает усиленный контроль качества (QA) и более строгое планирование функций. И тогда наша команда Delivery приняла невеселое решение: построила систему CD с имеющимися инструментами и реорганизовала инфраструктуру приложения GitLab.com — вместо того, чтобы сразу осваивать новый инструментарий и технологии CD.

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

Такой подход давал два ключевых преимущества:

Во-первых, мы выявили все слабые места в нашем подходе и стабилизировали их путем автоматизации с CI, так что наше приложение окрепло, а успех перехода на Kubernetes стал реальнее.

Во-вторых, настроив команду инженеров на CD, мы осуществили в умах инженеров GitLab, — привыкших к развертываниям каждую неделю и ждать, порой целый день, как они скажутся на мердже, — настоящий культурный сдвиг.

"С тех пор, как мы освоили CI/CD, наши разработчики стали по-новому понимать, что значит "готово"", — сказал Марин.

До внедрения CI/CD изменение считалось готовым, как только был закончен обзор. Это исключало развертывания в различные среды, что отнимало много времени. Сегодня же развертывания поставляются в течение нескольких часов, так что нет никаких причин не подтверждать работоспособность изменения в тестовой и производственной средах.

Внедрение приложений для обзора на Kubernetes позволяет разработчикам запускать проверки качества буквально в реальном времени, а применение флажков функций для прогрессивной поставки также ускоряет разработку.

"С самого первого шага в CD от разработчиков требуется реагировать на каждую автоматизированную проверку качества, а еще — выполнять подтверждения вручную на новом уровне как в производственной, так и в тестовой средах. Плюс к этому разработчики могут вносить изменения в производственной среде в течение одного дня, тогда как раньше на это уходило несколько дней (а то и недель)".

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

Наш новый метод

Внедрив систему CI/CD, мы автоматизировали 90% процесса. Оставшиеся 10% требуют человеческого вмешательства — нужна координация между множеством лиц с правом доступа.

"Мы постепенно сокращаем и эти 10% — чтобы нужны стали только одобрения для публикации релиза", — сказал Марин. В текущей итерации процесс CI/CD работает следующим образом:

CI автоматически ищет определенные метки в запросах на слияние, одобренных ревьюерами и разработчиками.
CI автоматически синхронизирует требуемые репозитории и при этом создает необходимые ветки Git, тэги, а также включает корректные версии выпуска, который мы хотим поставить.
Когда сборки завершены, пакеты автоматически развертываются в тестовые среды.
Выполняются автоматические проверки качества и, если все хорошо, развертывание поставляется небольшому сегменту пользователей в производственной среде.
Параллельно с этим разработчики выполняют проверку качества другого уровня вручную — чтобы убедиться, что новые функции работают как надо.
Если в ходе ручного подтверждения обнаруживается проблема высокой важности, развертывания останавливаются.
Когда предыдущий этап завершен, член команды Delivery запустит поставку развертывания для всех пользователей GitLab.com.
Затем на основе последнего рабочего развертывания, запущенного на GitLab.com, создается выпуск для индивидуальных клиентов.

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

Второй крупный вызов для нас — сложность системы GitLab.com и передача изменений прямо в процессе на все команды инженеров. "Нарушить установившийся за годы процесс и привычки — это совсем не просто", — сказал Марин.

Результаты

GitLab уже во многом выигрывает от перехода на CI/CD.

Наблюдения и оценка в 2019 году показали, что в те самые 14 дней перед релизом команда Delivery 82% времени проводит куда продуктивнее: оно высвободилось для работы над другими важными задачами.

Наблюдение за 2019 год показало, что в те же 2 недели у разработчиков освободилось очень много столь драгоценного времени — благодаря переходу на c CD.

Автоматизировав ручную работу, команда Delivery переключилась наконец на изменение инфраструктуры GitLab.com, чтобы улучшить поддержку скорости разработки и пользовательского трафика, а вместе с тем и миграции на Kubernetes.

"И, как я уже вроде говорил, все это — без Kubernetes. Все делалось на старой системе-предшественнице", — поведал Марин гостям бруклинского GitLab Commit. — "Зато мы выиграли время, так что теперь моя команда вплотную занимается миграцией. Однако одна из самых крупных перемен произошла именно в привычке организации разработки".

Результаты после перехода значительные. Если на старой системе в мае 2019 года команда поставляла где-то 7 развертываний, то в августе 2019 эта цифра выросла до 35. И это не предел: цифры значительно увеличатся — теперь, когда команда поставляет множество развертываний ежедневно.

"Мы только что мигрировали наш Сервис реестра на Kubernetes, и если вы используете реестр контейнеров на GitLab.com, все ваши запросы исполняются на платформе Kubernetes", — сказал Марин. — "GitLab — система многокомпонетная, и мы продолжаем изолировать и переносить другие сервисы".

В каждый новый выпуск включаются новые функции CI/CD. Например, в выпуске 12.3 мы расширили Реестр контейнеров GitLab — позволив пользователям использовать CI/CD и собирать и внедрять образы/тэги в собственные проекты. Были и другие новые восхитительные нововведения.

Тоже переводите систему на непрерывную поставку?

Компаниям, которые еще только собираются перейти на CD, Марин посоветовал начинать с тем, что есть.

"Как по мне, сидеть и ждать миграции на новую платформу — вредить себе", — сказал Марин. — "Большинство систем можно неким образом изменить и ускорить цикл обработки, не мигрируя на совершенно новую систему. Ускорения цикла разработка/релиз многократно увеличивает КПД каждого инженера в системе и высвобождает больше времени для миграции на новую платформу, например Kubernetes".

Если вам интересно, что будет дальше, загляните в эту детальную сводку по восхитительным новым функциям CI/CD, которые ждут своего часа — с выпуском 12.4 и далее.

Пропустили бруклинский GitLab Commit?

Если вы не смогли посетить презентацию Марина с предысторией нашего перехода на Kubernetes, смотрите полное видео — ниже, — и присоединяйтесь к нам на Европейском GitLab Commit в Лондоне, 9 октября.

К CI/CD и Kubernetes GitLab шел необычным путем