Команды инженеров постоянно испытывают давление: нужно выдавать новые функции в виде достойного продукта и при этом постоянно минимизировать время цикла. Зачастую специалисты не думая хватаются за современный инструментарий. Непрерывная интеграция и поставка (CI/CD) встроены в GitLab, наше единственное приложение для жизненного цикла DevOps, и сейчас мы, чтобы еще больше сократить время цикла, всем составом мигрируем на Kubernetes. Однако к CI/CD — и в конечном итоге Kubernetes — мы шли не совсем обычным путем. Команда Delivery, переводя нас на непрерывную поставку GitLab.com, напрягла старую систему, и только потом мы полностью перешли на Kubernetes. В период с 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 Commit, посвященной этой теме, Марин поделился результатами наблюдений за 2018 год: в двухнедельный период до релиза команда Delivery тратила 60% времени, сюсюкаясь с развертываниями, еще 26% — на ручное и полуручное выполнение задач вроде написания обзора ежемесячного выпуска. 
Результаты наблюдений за 2018 год, до перехода на непрерывную поставку: вот как команда Delivery расходовала время за 2 недели до релиза. "Если говорить в общем, то за 14 дней, за две недели до релиза команда только и делала, что пялилась в мониторы, глядя, как сохнет краска, что ли", — сказал Марин. Но взявшись за 86% этого пирога (60% на развертывания + 26% на ручное выполнение задач), команда Delivery решила бы ряд проблем: И хотя 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 изменение считалось готовым, как только был закончен обзор. Это исключало развертывания в различные среды, что отнимало много времени. Сегодня же развертывания поставляются в течение нескольких часов, так что нет никаких причин не подтверждать работоспособность изменения в тестовой и производственной средах. Внедрение приложений для обзора на Kubernetes позволяет разработчикам запускать проверки качества буквально в реальном времени, а применение флажков функций для прогрессивной поставки также ускоряет разработку. "С самого первого шага в CD от разработчиков требуется реагировать на каждую автоматизированную проверку качества, а еще — выполнять подтверждения вручную на новом уровне как в производственной, так и в тестовой средах. Плюс к этому разработчики могут вносить изменения в производственной среде в течение одного дня, тогда как раньше на это уходило несколько дней (а то и недель)". С CD можно проводить проверки качества кода гораздо чаще. А поскольку у нас с нашей системой CI/CD изменения в коде поставляются круглосуточно, разработчики выполняют ротацию по запросу при любых нестандартных проблемах, вскрывающихся в реальном времени, поскольку "инкубационный период" сильно сократился. Внедрив систему CI/CD, мы автоматизировали 90% процесса. Оставшиеся 10% требуют человеческого вмешательства — нужна координация между множеством лиц с правом доступа. "Мы постепенно сокращаем и эти 10% — чтобы нужны стали только одобрения для публикации релиза", — сказал Марин. В текущей итерации процесс CI/CD работает следующим образом: Как и для любой другой команды инженеров, масштабирование для нас — настоящий вызов. Впрочем, один из самых больших вызовов для технарей — это убедиться, что проверка качества покрывает все, а ведь для крупного проекта вроде GitLab.com это интенсивный труд. А еще надо убедиться, что хватает мониторинга и оповещения, для того, чтобы проект работал не на одних только предустановленных правилах. Второй крупный вызов для нас — сложность системы GitLab.com и передача изменений прямо в процессе на все команды инженеров. "Нарушить установившийся за годы процесс и привычки — это совсем не просто", — сказал Марин. GitLab уже во многом выигрывает от перехода на CI/CD. Наблюдения и оценка в 2019 году показали, что в те самые 14 дней перед релизом команда Delivery 82% времени проводит куда продуктивнее: оно высвободилось для работы над другими важными задачами. 
Наблюдение за 2019 год показало, что в те же 2 недели у разработчиков освободилось очень много столь драгоценного времени — благодаря переходу на c CD. Автоматизировав ручную работу, команда Delivery переключилась наконец на изменение инфраструктуры GitLab.com, чтобы улучшить поддержку скорости разработки и пользовательского трафика, а вместе с тем и миграции на Kubernetes. Результаты после перехода значительные. Если на старой системе в мае 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 октября.