Как наша команда 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 октября.