Как мы выпускаем исправления к ПО в GitLab

Мы в GitLab обрабатываем исправления ПО двумя способами — «ручками» и автоматически. Читайте далее о работе release manager по созданию и доставке важных обновлений с помощью автоматического развертывания на gitlab.com, а также исправлений для пользователей, которые работают со своими установками.

Рекомендую поставить напоминание на своих умных часах: каждый месяц 22 числа пользователи, работающие с GitLab на своих мощностях, могут увидеть обновления актуальной версии нашего продукта. В ежемесячном выпуске можно найти новые функции, развитие уже существующих, а также часто можно увидеть конечный результат запросов, отправленных сообществом, на инструментарий или слияние.

Но, как показывает практика, разработка ПО редко бывает без изъянов. При обнаружении ошибки или уязвимости в системе безопасности, release manager в команде доставки создает исправление для наших пользователей со своими установками. Gitlab.com обновляется в процессе CD. Мы называем этот процесс CD автоматическим развертыванием, чтобы не было смешивания с функцией CD в GitLab. Этот процесс может включать предложения из запросов на слияние, отправленных пользователями, клиентами и нашей внутренней командой разработки, так что решение скучной проблемы выпуска исправлений решается двумя весьма сильно различающимися способами.

«Мы ежедневно обеспечиваем развертывание всего, что сделали разработчики, на всех окружениях, прежде чем выкатить это на GitLab.com», поясняет Marin Jankovki, старший технический менеджер инфраструктурного отдела. «Воспринимайте выпуски для своих установок, как снимки для развертывания gitlab.com, для которых мы добавили отдельные действия по созданию пакета, чтобы наши пользователи могли использовать его для установки на своих мощностях».

Независимо от ошибки или уязвимости, клиенты gitlab.com получат исправления вскоре после их публикации, что является преимуществом автоматического процесса CD. Исправления для пользователей со своими установками требуют отдельной подготовки, выполняемой release manager.

Команда доставки усиленно работает над автоматизацией большинства процессов, связанных с созданием выпусков для сокращения MTTP (mean time to production, т.е. времени, затраченного на производство), промежутка времени от обработки запроса на слияние разработчиком до развертывания на gitlab.com.

«Цель команды доставки — убедиться, что мы можем работать быстрее, как компания, или, по крайней мере, ускорить работу людей по доставке, верно?», говорит Marin.

Как клиенты gitlab.com, так и пользователи своих установок получают выгоду от усилий команды доставки по сокращению времени цикла и ускорению развертывания. В этой статье мы поясним сходство и различие между этими двумя способами выпусков, а также опишем, как наша команда доставки готовит исправления для пользователей, работающих на своих мощностях, а также как обеспечивается актуальность gitlab.com с помощью автоматического развертывания.

Что делает release manager?

Члены команды ежемесячно передают роль release manager наших выпусков для пользователей на своих мощностях, включая исправления и выпуски безопасности, которые могут происходить между выпусками. Также они отвечают за переход компании на автоматическое, непрерывное развертывание.

Выпуски для установки на своих мощностях, а также выпуски gitlab.com используют похожие рабочие процессы, но работают в разное время, поясняет Marin.

В первую очередь release manager, независимо от типа выпуска, обеспечивает доступность и безопасность GitLab с момента запуска приложения на gitlab.com, включая гарантию того, что одинаковые проблемы не попадут в инфраструктуру клиентов со своими мощностями.

Как только в GitLab ошибка или уязвимость помечается исправленной, release manager должен оценить, что она попадет в исправления или обновления безопасности для пользователей со своими установками. Если он решит, что ошибка или уязвимость заслуживают обновления — начинается подготовительная работа.

Release manager должен решить, готовить ли исправление, или когда его разворачивать — и это сильно зависит от контекста ситуации, «а пока машины не так хорошо управляются с контекстом, как люди», говорит Marin.

Все насчет исправлений

Что такое исправления, и почему они нам нужны?

Release manager принимает решение о выпуске исправления в зависимости от серьезности ошибки.

Ошибки различаются в зависимости от их серьезности. Так ошибки S4 или S3 могут быть стилистическими, например смещение пикселя или значка. Это не менее важно, однако тут нету особого влияния на чей-то рабочий процесс, а значит вероятность того, что исправление будет создано для таких ошибок S3 или S4, мала, поясняет Marin.

Однако уязвимости S1 или S2 означают, что пользователь не должен обновляться до последней версии, или есть значительная ошибка, влияющая на рабочий процесс пользователя. Если таковые попадают в трекер — многие пользователи столкнулись с ними, поэтому release manager сразу же начинает подготовку исправления.

Как только исправление для уязвимостей S1 или S2 готово, release manager запускает выпуск исправления.

К примеру исправление GitLab 12.10.1 было создано после того, как выявились несколько блокирующих проблем, а разработчики устранили основную проблему, приводившую к ним. Release manager провел оценку правильности присвоенных уровней серьезности, а после подтверждения был запущен процесс выпуска исправления, который был готов в течение суток после обнаружения блокирующих проблем.

Когда накапливается много S4, S3 и S2 — release manager смотрит контекст для определения срочности выпуска исправления, а при достижении некоторого их числа — они все объединяются и выпускаются. Исправления или обновления безопасности после выпуска кратко описываются в сообщениях блога.

Как release manager создает исправления

Мы применяем GitLab CI и другие функции, например наш ChatOps, для создания исправлений. Release manager запускает выпуск исправления путем активации команды ChatOps на нашем внутреннем канале #releases в Slack.

/chatops run release prepare 12.10.1

ChatOps работает в Slack, чтобы активировать разные события, которые затем обрабатывает и выполняет GitLab. Например, команда доставки провела настройку ChatOps для автоматизации разных вещей для выпуска исправлений.

Как только release manager запускает команду ChatOps в Slack, остальная работа происходит автоматически в GitLab с использованием CICD. Между ChatOps в Slack и GitLab в процессе выпуска происходит двухсторонний обмен данными, поскольку release manager активирует некоторые из основных этапов процесса.

На видео ниже предоставлен технический процесс подготовки исправления для GitLab.

Как устроено автоматическое развертывание gitlab.com

Сам процесс и инструменты, используемые при обновлении gitlab.com, похожи на таковые, используемые при создании исправлений. Обновление gitlab.com требует меньше ручной работы с точки зрения release manager.

Вместо запуска развертывания с использованием ChatOps мы используем функции CI, например scheduled pipelines, с которыми release manager может запланировать выполнение определенных действий в требуемое время. Вместо ручного процесса есть конвейер, запускаемый периодически один раз в час, который скачивает внесенные новые изменения в проектах GitLab, упаковывает их и планирует развертывание, а также автоматически запускается тестирование, QA и другие необходимые шаги.

«Итак, мы имеем много развертываний, запущенных в различных окружениях, до gitlab.com, а после того, как эти окружения будут в хорошем состоянии, и тестирование покажет хорошие результаты, release manager запускает действия по развертыванию gitlab.com», рассказывает Marin.

Технология CICD для поддержки обновлений gitlab.com автоматизирует весь процесс до момента, когда release manager должен руками запускать развертывание производственного окружения на gitlab.com.

Marin подробно рассказывает о процессе обновления gitlab.com на видео ниже.

Что еще делает команда доставки

Основное различие между процессами обновления gitlab.com и выпуском исправлений для клиентов на своих мощностях заключается в том, что последний процесс требует больше времени и большего количества ручной работы от release manager.

«Иногда мы откладываем выпуск исправлений для клиентов со своими установками из-за переданных проблем, проблем с инструментами, а также потому, что есть много нюансов, которые надо учитывать при выпуске единого исправления», говорит Marin.

Одна из краткосрочных целей команды доставки — уменьшить объемы ручной работы со стороны release manager для ускорения выпуска. Команда работает над упрощением, оптимизацией и автоматизацией процесса выпуска, что поможет быстрее избавиться от исправлений для проблем с низким уровнем серьезности (S3 и S4, прим. переводчика). Ориентация на скорость — ключевой показатель производительности: надо уменьшать MTTP — время, с приема запроса на слияние и до развертывания результата на gitlab.com — с текущих 50 часов до 8 часов.

Команда доставки также работает над переходом gitlab.com на инфраструктуру на основе Kubernetes.

N.B. редактора: Если вы уже слышали о технологии Kubernetes (а я даже и не сомневаюсь, что слышали), но ещё не пощупали её руками, рекомендую поучаствовать в онлайн-интенсивах Kubernetes База, который пройдёт 28-30 сентября, и Kubernetes Мега, который пройдёт 14–16 октября. Это позволит вам уверенно ориентироваться в технологии и работать с ней.

Это два подхода, преследующих одну и ту же цель: быстрая доставка обновлений, как для gitlab.com, так и для клиентов на своих мощностях.

Есть идеи и рекомендации для нас?

Каждый может принять участие в разработке GitLab, мы приветствуем отзывы от наших читателей. Если у вас есть идеи для нашей команды доставки — не стесняйтесь создать заявку с пометкой team: Delivery.

Источник: habr.com