Как наша команда доставки, используя только собственные ресурсы, перестроила нашу систему для CI/CD.
Команды инженеров постоянно находятся под давлением необходимости реализовать новые функции в достойном продукте, постоянно сводя к минимуму время цикла .Зачастую специалисты не задумываясь хватаются за современные инструменты.
Непрерывная интеграция и доставка (CI/CD) встроены в GitLab, наше единственное приложение жизненного цикла DevOps, и мы переводим всю команду на Kubernetes, чтобы еще больше сократить время цикла.
Однако наш путь к CI/CD — и, в конечном итоге, к Kubernetes — был не совсем обычным.
Команда доставки , переводя нас на непрерывную доставку GitLab.com, напрягал старую систему, и только потом мы полностью перешли на Kubernetes.
Как мы выпускали релизы до CI/CD
В период с 7 августа по 27 сентября 2019 года огромное сообщество GitLab и члены нашей команды совершили в среднем 55 коммитов.в день — это непрерывные итерации нашего продукта для создания новых функций.
Но прежде чем мы внедрили непрерывную поставку, мы использовали периоды заморозки функций, которые начинались 7-го числа каждого месяца: в это время наши инженеры переключали свое внимание с разработки новых функций и отладки на подготовку к предстоящим выпускам, которые последовательно выходят 22-го числа каждого месяца.
месяц.
Введя строгие сроки, мы привили разработчикам такое поведение, которое помогло им в конечном итоге сосредоточиться на конкретной дате, а не на доступности.
«.
разработчики начали плясать вокруг даты «7-го», потому что посмотрели на календарь и подумали: ну время еще есть, через неделю 7-е, — и тут, в полночь 6-го, они начали лихорадочно проводить слияния», — заявил Марин Янковски , технический директор команды Delivery. «Они знают: если они пропустят срок, им придется ждать еще месяц, а если они успеют вовремя, у них будет еще добрых две недели на отладку».
С момента создания GitLab.com периоды заморозки функций использовались как время для стабилизации», — объяснил Марин.
Однако количество пользователей росло, а потребность в новых функциях заставила нас ускорить темпы разработки.
Период стабилизации замедлил цикл и сильно задержал переход к отладке, регрессу и доставке функций — как пользователям Gitlab.com, так и отдельным клиентам.
«В некоторых случаях [зависания новых функций] даже провоцировали нестабильность платформы — из-за того, что исправления с наивысшим приоритетом не доходили до клиента вовремя», — сказал Марин.
«Переходя на CI/CD, мы выпускаем новые продукты и отлаживаем их гораздо быстрее».
Прежде чем мы сформировал команду доставки для перевода GitLab.com на непрерывную доставку , — и в конце концов от Kubernetes — мы зависели от менеджер релизов .
Это была ротационная позиция среди разработчиков, которую занимал тот, кто готовил новый релиз.
Мы повторяли этот процесс более 5 лет , но релиз-менеджеры создали базу знаний и более-менее автоматизировали ее.
Однако метод оказался неэффективным, поскольку график развертывания и подготовки релизов колебался от полудня до нескольких дней из-за того, что накопившиеся в процессе задачи для ручного выполнения .
«Релиз-менеджер получал фиксированный список задач, сроки и повторял перечисленные шаги снова и снова, пока на GitLab.com не был получен полностью готовый и стабильный релиз», — объяснил Марин.
В самом общем смысле от релиз-менеджера требовалось сделать следующее:
- Вручную синхронизируйте множество репозиториев, составляющих GitLab.
- Убедитесь, что в созданные вручную ветки Git включены правильные версии.
- После того как выпуск будет помечен, вручную разверните его на GitLab.com для тестовых и производственных сред.
- Убедитесь, что все работает, и вручную публикуйте пакеты для отдельных пользователей.
Наблюдения из 2018 года, до перехода на непрерывную доставку: вот как команда доставки провела время за 2 недели до релиза.
«Вообще, за 14 дней, за две недели до релиза команда ничего не делала, кроме как смотрела в мониторы, наблюдая, как сохнет краска или что-то в этом роде», — сказал Марин.
Но взяв на себя 86% этого пирога (60% на развертывания + 26% на ручные задачи), команда доставки решила бы ряд проблем:
- Новые релизы без задержек.
- Повторяемое и быстрое развертывание без простоев.
- Больше времени для миграции GitLab.com в Kubernetes.
- Больше свободы в подготовке вашей организации к непрерывной работе.
Теперь все, что не затрагивается CI-тестированием, тестируется автоматически и вручную в средах — перед попаданием на GitLab.com. Все, что поступает на GitLab.com и требует отладки, будет отлажено в течение нескольких часов.
Таким образом, финальная версия для индивидуальных клиентов будет чистой.
Переход от периодов заморозки к компакт-диску был вопросом времени, поскольку наш набор функций рос, и появилась команда инженеров во главе с Марином, чтобы наблюдать за переходом: «Команда доставки была сформирована с единственной целью — перевести компанию на модель компакт-диска.
и в то же время перевести компанию на платформу Kubernetes для упрощения масштабирования и сокращения времени цикла».
Большинство компаний на месте GitLab начали бы переход на CI/CD и Kubernetes с первой интеграции новых технологий в свой рабочий процесс и попутного исправления процесса разработки.
Мы выбрали другой подход. Миграция на Kubernetes требует изменения не только производственной системы, но и подхода к разработке, пояснил Марин.
Kubernetes предлагает определенные функции, которые легко доступны без дополнительных инвестиций.
Но чтобы действительно извлечь выгоду из бесплатных возможностей, предлагаемых Kubernetes, вам нужен какой-то CI/CD. Команда доставки усвоила это: чтобы облегчить переход на Kubernetes для непрерывной доставки, наши инженеры уже должны работать с прицелом на CI/CD, что означает более строгий контроль качества (QA) и более тщательное планирование функций.
И затем наша команда доставки приняла печальное решение : Создал систему компакт-дисков с использованием существующих инструментов и реорганизовал инфраструктуру приложений GitLab.com — вместо того, чтобы переходить к новым инструментам и технологиям компакт-дисков.
«Идея была проста, — сказал Марин, — мы Мы используем те инструменты, которые есть в нашем распоряжении , мы автоматизируем большинство ручных задач и проводим нагрузочное тестирование всей статической системы.
Если статическая система выдержит, мы переходим к динамическим испытаниям».
Такой подход обеспечил два ключевых преимущества: Во-первых , мы выявили все слабые места в нашем подходе и стабилизировали их за счет автоматизации с помощью CI, чтобы наше приложение стало сильнее, а успех перехода на Kubernetes стал более реальным.
Во-вторых Создав команду инженеров на компакт-диске, мы произвели настоящий культурный сдвиг в сознании инженеров GitLab: они привыкли к развертываниям каждую неделю и ждут, иногда целый день, их влияния на слияние.
«С тех пор, как мы внедрили CI/CD, наши разработчики выработали новое понимание того, что означает слово «готово», — сказал Марин.До внедрения CI/CD изменение считалось готовым сразу после завершения проверки.
Это позволило избежать трудоемких развертываний в различных средах.
Сегодня развертывание осуществляется в течение нескольких часов, поэтому нет причин не проверять изменения в тестовой и производственной средах.
Внедрение приложений проверки в Kubernetes позволяет разработчикам выполнять проверки качества буквально в режиме реального времени, а приложения функциональные флаги прогрессивная доставка также ускоряет разработку.
«С самого первого шага в разработке компакт-дисков разработчики обязаны реагировать на каждую автоматизированную проверку качества, а также выполнять ручное утверждение на следующем уровне как в производственной, так и в тестовой среде.
Кроме того, разработчики могут вносить изменения в производственную среду в течение дня, тогда как раньше это занимало несколько дней (или даже недель)».
С помощью компакт-диска вы можете проводить проверки качества кода гораздо чаще.
А поскольку с нашей системой CI/CD изменения в коде поставляются круглосуточно, разработчики ротируются по требованию при любых нестандартных проблемах, выявляемых в реальном времени, поскольку «инкубационный период» существенно сократился.
Наш новый метод
представив CI/CD-система , мы автоматизировали 90% процесса.Остальные 10% требуют вмешательства человека — необходима координация между многими людьми, имеющими права доступа.
«Мы постепенно сокращаем эти 10%, чтобы для публикации релиза требовалось только одобрение», — сказал Марин.
В текущей итерации процесс CI/CD работает следующим образом.
:
- CI автоматически ищет определенные теги в мерж-реквестах, одобренных рецензентами и разработчиками.
- CI автоматически синхронизирует необходимые репозитории и при этом создает необходимые ветки Git, теги, а также включает правильные версии релиза, которые мы хотим поставить.
- По завершении сборки пакеты автоматически развертываются в тестовых средах.
- Выполняются автоматические проверки качества, и, если все в порядке, развертывание предоставляется небольшому сегменту пользователей в производственной среде.
- В то же время разработчики выполняют еще один уровень ручного контроля качества, чтобы гарантировать, что новые функции работают должным образом.
- Если во время проверки вручную обнаруживается серьезная проблема, развертывания останавливаются.
- После завершения предыдущего шага член команды доставки начнет доставлять развертывание всем пользователям GitLab.com.
- Затем создается пользовательский выпуск на основе последнего производственного развертывания, запущенного на GitLab.com.
Однако одна из самых больших проблем для технических специалистов — обеспечить обеспечение качества всего, а это интенсивная работа для такого большого проекта, как GitLab.com. Также необходимо убедиться, что мониторинга и уведомлений достаточно, чтобы проект не работал только по заданным правилам.
Второй большой вызов для нас — сложность системы GitLab.com и передача изменений непосредственно в процесс всем инженерным командам.
«Нелегко сломать процессы и привычки, сложившиеся годами», — сказал Марин.
Результаты
GitLab уже получил большую выгоду от перехода на CI/CD. Наблюдения и оценки в 2019 году показали, что за те самые 14 дней до релиза команда Delivery потратила 82% своего времени гораздо продуктивнее: оно освободилось для работы над другими важными задачами.
Наблюдение за 2019 год показало, что за те же 2 недели разработчики высвободили массу ценного времени — благодаря переходу на CD. Автоматизировав ручную работу, команда доставки наконец приступила к изменению инфраструктуры GitLab.com, чтобы лучше поддерживать скорость разработки и пользовательский трафик, а вместе с этим и переход на Kubernetes.
«И, как я уже сказал, всё это без Kubernetes. Все делалось на старой системе-предшественнице», — рассказал Марин гостям бруклинского GitLab Commit. «Но мы выиграли время, и теперь моя команда активно занимается миграцией.Результаты после перехода значительны.Однако одно из самых больших изменений произошло в привычках организаций-разработчиков».
Если на старой системе в мае 2019 года команда выполнила около 7 развертываний, то в августе 2019 года эта цифра увеличилась до 35. И это не предел: цифры вырастут в разы — теперь, когда команда выполняет много развертываний ежедневно.
«Мы только что перенесли нашу службу реестра в Kubernetes, и если вы используете реестр контейнеров на GitLab.com , все ваши запросы выполняются на платформе Kubernetes», — сказал Марин.
«GitLab — многокомпонентная система, и мы продолжаем изолировать и мигрировать другие сервисы».
Каждый новый выпуск включает новые функции CI/CD. Например, в версии 12.3 мы расширен реестр контейнеров GitLab, позволяющий пользователям использовать CI/CD, а также собирать и внедрять образы/теги в свои собственные проекты.
.
Были и другие интересные нововведения.
Вы тоже переводите систему на непрерывную доставку?
Компаниям, которые только планируют перейти на компакт-диски, Марин посоветовал начать с того, что у них есть.«По моему мнению, сидеть и ждать перехода на новую платформу вредно», — сказал Марин.
«Большинство систем можно каким-либо образом модифицировать, чтобы ускорить время выполнения работ без перехода на совершенно новую систему.
Ускорение цикла разработки/выпуска значительно повышает эффективность работы каждого инженера системы и освобождает больше времени для перехода на новую платформу, например Kubernetes».
Если вам интересно, что будет дальше, посмотрите это подробный обзор интересных новых функций CI/CD , которые ждут своего часа - с выходом 12.4 и далее.
Пропустили Бруклинский коммит GitLab? Если вы не смогли присутствовать на презентации Марина, посвященной нашему переходу на Kubernetes, посмотрите полное видео ниже и присоединяйтесь к нам на Европейский комитет GitLab в Лондоне, 9 октября .
Теги: #Системное администрирование #Администрирование серверов #DevOps #k8s #meetups #ci/cd #gitlab #gitlab.com #миграция на k8s
-
Старый Новый Звук Высокой Четкости
19 Oct, 24 -
Страшные Сказки На Ночь О Шине Pci
19 Oct, 24 -
Статистика Использования Офисных Пакетов
19 Oct, 24
