[Перевод] К CI/CD и Kubernetes GitLab шел необычным путем

a2i8t3d87zjmo0pom_thmcaumlo.jpeg


Как наша команда 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% — на ручное и полуручное выполнение задач вроде написания обзора ежемесячного выпуска.

nyhnbxt_uxf66q_lhtpqwo0aadu.png
Результаты наблюдений за 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% времени проводит куда продуктивнее: оно высвободилось для работы над другими важными задачами.

didj6fhpbxlkvmcwawkithvyjjw.png
Наблюдение за 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 октября.


© Habrahabr.ru