[Перевод] К CI/CD и Kubernetes GitLab шел необычным путем
Как наша команда 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 октября.
