Что такое Continuous Merge?
Несмотря на улучшения рабочего процесса разработки, связанного с внедрением pull request и код ревью, которые основывается на применение CI/CD у этих подходов есть некоторые проблемы. Эти проблемы можно устранить с помощью continuous merge (непрерывного слияния) — набора процессов, которые упрощают pull requests и ускоряют процесс код ревью.
В этой статье я хочу подробно рассмотреть, что такое continuous merge (непрерывное слияние), зачем оно нужно и как его реализовать с помощью таких инструментов автоматизации, как gitStream.
Что такое CI/CD
Continuous integration/continuous delivery (непрерывная интеграция/непрерывная поставка) (CI/CD) стало стандартной практикой для быстрой доставки новых функций программного обеспечения, исправления ошибок и процесса внедрения улучшений.
Continuous integration (CI – Непрерывная интеграция) — это когда разработчики объединяют отдельные части кода в центральный репозиторий, где выполняются автоматизированные тесты и сборка.
Continuous delivery (CD – Непрерывная доставка) автоматизирует развертывание изменений кода в тестовых и производственных средах. Continuous deployment (Непрерывное развертывание) — термин, который часто путают с непрерывной доставкой, — это последний этап конвейера DevOps, на котором все изменения, успешно прошедшие производственный конвейер, передаются клиентам.
CI/CD автоматизирует каждый этап процесса разработки, гарантируя, что продукты и функции доставляются пользователям почти так же быстро, как они разрабатываются. Но у него есть недостатки.
Как можно улучшить CI/CD
Когда несколько разработчиков одновременно работают над большой кодовой базой, неизбежно создается множество веток (branches) от центральной ветки. Ветки с длительным временем жизни (период между код ревью и слиянием) препятствуют улучшению производительности, которого стремятся добиться такие гибкие методологии как CI/CD.
Неэффективность процесса pull-request (PR) создает узкие места в конвейере доставки, особенно когда код ревью занимает несколько дней.
Для оптимальной производительности CI/CD должно быть не более трех веток со сроком жизни не более суток до слияния с основной. Но в большинстве команд разработки это практически неслыханная роскошь.
Ревью pull request, которое занимает несколько дней или недель, имеет значительные финансовые последствия. Помимо невыполненных работ, отложенные ревью могут вызвать сложные конфликты слияния (merge conflicts). Хуже того, pull requests поступают до интегрированного тестирования в конвейере CI/CD, поэтому успешная проверка не гарантирует аналогичный результат позже.
Решением этих узких мест в конвейере является continuous merge (непрерывное слияние).
Определение Continuous Merge
Непрерывное слияние — это набор процессов, которые помогают устранить узкие места, мешающие pull requests и код ревью.
Стандартной практикой для инженерных проектов является управление кодовой базой через систему контроля версий (VCS), где объединяется код всех разработчиков.
Репозитории VCS обычно имеют одну или несколько веток, а обычно код ревью требует ручной проверки перед слиянием с основной веткой.
Зачем нужен Continuous Merge
Типичная проверка кода включает в себя участника или разработчика, открывающего pull request и информирующего других соавторов о том, что изменения кода были отправлены в ветку и требуют проверки (и последующего утверждения) перед слиянием с основной веткой.
PR позволяют соавторам, обычно ведущим или старшим разработчикам, проверять изменения на предмет соблюдения качества, а затем выполнить одно из следующих трех действий
- Добавить комментарии по предлагаемым изменения.
- Подтвердить изменения.
- Запросить дальнейшие изменения перед возможным объединением веток.
Этот процесс характеризуется множеством проблем, что часто приводит к тому, что PR занимает больше времени, чем нужно.
Например:
- Коллега может начать просмотр PR, а затем преждевременно остановиться, чтобы заняться другими обязанностями.
- Как результат процесс зависает, так как разработчики вовремя не получают обратной связи, и слияние откладывается.
- Если репозиторий имеет много веток с несколькими участниками, это может повлиять на весь конвейер CI/CD, что может привести в будущем к конфликтам слияния и снижению производительности труда разработчиков.
Другие проблемы, которые замедляют традиционные ревью, включают:
- Слишком большие PR;
- Перегруженные команды;
- Отвлечение сотрудников на другие задачи; или же
- Неоптимальное назначение PR людям, так что желаемый результат не достигается при первоначальном запросе.
Для устранения подобных проблем в этом процессе требуют реорганизации всего процесса код ревью PR.
Как Continuous Merge упрощает код ревью
pull request, также известный как запрос на слияние (merge request), — это когда разработчики или участники указывают, что изменения кода готовы для слияния с основным репозиторием проекта. Это стандартная отраслевая практика для других разработчиков, руководителей групп и других сторон проверять изменения кода перед слиянием, человеческий вклад в этот процесс неизбежен.
Исторически сложилось так, что этот процесс pull request приводил к неэффективности, в частности к задержкам проверки, поскольку процесс не автоматизирован, поэтому скорость зависит от наличия подходящего рецензента кода.
Continuous merge направлено на улучшение процесса проверки pull request за счет введения уровня автоматизации, который обеспечивает автоматическое утверждение и эффективную маршрутизацию сложных pull requests соответствующим рецензентам.
Continuous merge учитывает уникальные характеристики отдельных pull requests и соответствующим образом направляет их в соответствии с моделью, основанной на оценке рисков, что обеспечивает оптимизацию процесса и устранение узких мест.
Continuous merge классифицирует pull requests и код ревью в соответствии с их характеристиками — типом, сложностью кода и размером.
Это создает автоматические линии pull requests, которые повышают скорость и эффективность слияния.
3 важных шага к Continuous Merge
Шаг 1. Предоставьте контекст для Pull Requests, чтобы их было легче классифицировать
Первый шаг — понять контекст pull request. Pull requests одинаково обрабатываются большинством систем контроля версий, которые предоставляют одинаковую информацию для каждой из них — но этого недостаточно, чтобы рецензент мог оценить их размер или сложность.
Continuous merge добавляет контекстуальный уровень с дополнительной информацией, такой как предполагаемое время проверки, описание компонента проекта и владельца pull request.
Шаг 2. Обрабатывайте запросы на слияние по-разному в зависимости от их размера и характеристик
Второй шаг включает в себя классификацию pull request в соответствии с контекстной информацией. Этот процесс признает, что pull request различаются по размеру — некоторые из них состоят всего из нескольких строк кода, а другие занимают много места. Несмотря на это, pull request проходят аналогичный процесс, и даже те, которые можно выполнить быстро, могут растянуться на несколько дней из за код ревью.
Этап маршрутизации непрерывного слияния направлен на устранение такого недостатка, полагаясь на классификацию PR для отправки pull request с несколькими строками кода для почти мгновенного рассмотрения и утверждения. Расширение WorkerB Chrome extension для pull requests упрощает создание и доставку контекстно-обогащенных PR для рецензентов кода.
Шаг 3. Оптимизируйте Pull Requests с низким уровнем риска
Третий и последний шаг непрерывного слияния — применение автоматизации и инструментов на основе правил для автоматического утверждения и слияния pull request с низким уровнем риска при оптимизации маршрутизации других в зависимости от их уровня риска.
Почему непрерывное слияние лучше традиционного слияния
Традиционный рабочий процесс слияния включает в себя строго определенные шаги, при этом все pull request — будь то пять строк или критическое изменение в 100 строк — обрабатываются одинаково.
Точно так же изменения в статических файлах, которые могут быть утверждены и объединены автоматически, обрабатываются через тот же конвейер. Когда проверки кода откладываются на несколько дней, возрастает риск возникновения конфликтов слияния, а время простоя между проверками запросов на включение может привести к снижению производительности разработчиков.
Непрерывное слияние, напротив, устраняет эти узкие места конвейера CI/CD, контекстуализируя PR-запросы и классифицируя их с помощью модели, определенной командой. В соответствии со стандартными методами DevOps pull request размещаются в соответствующих дорожках для непрерывного слияния с помощью автоматизированных инструментов.
Как легко реализовать непрерывное слияние в вашей команде
gitStream поможет реализовать непрерывное слияние.
gitStream отличается от стандартного процесса код ревью, тем что автоматизируя одобрение слияния для небольших pull request с низким уровнем риска и направляя другие типы правок кода соответствующим рецензентам.
Инструмент использует модель автоматизации на основе правил, которая расширяет возможности как разработчиков, так и рецензентов.
Непрерывное слияние также пытается обеспечить, чтобы обзоры доставались наиболее подходящим людям, поэтому необходимо подумать о типе кода и о том, кто назначен для его проверки.
Вы можете создать правила автоматизации в файле .cm, чтобы предоставить параметры и ограничения, определяющие, как код проверяется и впоследствии объединяется. Этот файл улучшает классификацию PR, позволяя рецензентам получить больше контекста по запросу PR, чтобы они могли расставить приоритеты отзывов в соответствии с такими характеристиками, как сложность и размер.
Вот обзор того, как gitStream обеспечивает непрерывное слияние с помощью правил, указанных в файле .cm:
- Автоматическое одобрение pull request, содержащих небольшие изменения кода, которые успешно прошли модульное тестирование.
- Автоматическое назначение pull request соответствующим отдельным рецензентам в зависимости от сложности кода, предполагаемого времени рецензирования и опыта рецензента.
- Автоматическое назначение pull request, содержащих критические изменения, идеальным группам проверки посредством кодификации пользовательских правил.
Начать работу с gitStream несложно, поскольку этот инструмент легко интегрируется с вашими удаленными репозиториями. Например, чтобы настроить gitStream на GitHub, выполните следующие три простых шага.
Файл .cm (.cm/gitstream.cm) позволяет создавать настраиваемые конструкции автоматизации, включая определение переменных контекста, функции фильтрации, которые можно вызывать для переменных контекста, и действия автоматизации, запускаемые при выполнении всех условий (правил).
Механизм gitStream запускает пользовательскую автоматизацию, определенную в файле .cm. Движок поддерживает некоторые общие действия, включая добавление комментариев, добавление меток, добавление рецензентов, утверждение, слияние, установку требуемых утверждений и требование рецензентов.
Непрерывное слияние завершает Promise of CI/CD
Традиционные ревью PR и рабочие процессы слияния, как правило, создают узкие места в процессе CI/CD.
Проверка и код ревью могут привести к задержкам на несколько дней, даже если некоторые из них не представляют большого риска и могут быть быстро решены. Поскольку все pull requests обрабатываются одинаково, эффективность этого процесса еще предстоит повысить.
Непрерывное слияние является многообещающим решением этих проблем. Благодаря непрерывному слиянию разработчики могут создавать собственные правила для своих pull requests, оптимизируя процесс проверки.
Посмотрите это выступление нашего директора по Developer Experience Люка Килпатрика, чтобы узнать больше о непрерывном слиянии и gitStream:
Хотите сократить время проверки кода до 40 %? Добавляйте предполагаемое время проверки автоматически!
gitStream — это бесплатный инструмент разработки от LinearB, который устраняет узкое место № 1 в рабочем процессе вашей команды: pull requests и код ревью. Изучив работу 2000 команд разработчиков, инженеры и специалисты по обработке и анализу данных LinearB обнаружили, что время сбора и код ревью длилось на 4–5 дней дольше, чем должно быть.
Хорошей новостью является то, что они обнаружили, что эти задержки могут быть устранены в основном путем добавления расчетного времени проверки к pull requests!