Git предоставляет множество стратегий ветвления и методов рабочего процесса.Когда мы подробно изучаем рабочие процессы Git в отрасли, каждый рабочий процесс очень хорошо разработан, и кажется, что его можно применять в командной практике. Но будьте осторожны при разработке спецификации рабочего процесса Git: рабочий процесс Git — это только часть всего процесса разработки. Вышестоящая система управления проектами/отслеживания дефектов присматривается, а нижестоящая CD (непрерывная поставка) ожидает загрузки.Необходимо учитывать такие факторы, как размер команды, форма продукта, метод выпуска и т. д. Поэтому реализовать спецификацию рабочего процесса Git в команде — непростое решение.

Эффективный охват CR (Code Review) репозитория ByteDance Git составляет 70%, и еще есть возможности для улучшения.Благодаря исследованиям большая часть команды использует модель GitHub Flow. Поскольку построение байтовой эффективности НИОКР становится все более и более совершенным, GitHub Flow не может в полной мере использовать возможности НИОКР для повышения эффективности и обеспечения качества проекта.Многие команды осознают это и начинают строить спецификации процессов.

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

Введение в рабочий процесс Git в отрасли

Git Flow

Младшие разработчики Git, столкнувшись с этой картой веток и точек слияния, просто хотят порвать автора за руку. У продвинутых разработчиков Git много головной боли, пытаясь реализовать этот процесс на практике.

Git Flow имеет много преимуществ:

• Каждая ветвь выполняет свои обязанности, охватывая большинство сценариев разработки.
• Ожидается, что любые коммиты в основной ветке можно будет развернуть.
• Строго следуйте процессу, количество крупных аварий будет значительно снижено.

Недостатков тоже много:

• Слишком громоздко, чтобы требовать от всех членов команды строго следовать этому процессу.
• Нарушает недолговечный принцип ветвления, за который выступает git.
• История основной ветки не является чистой, только пометкой того, что мастер фактически развертывает.
• Не подходит для непрерывного развертывания и монорепозиториев.

GitHub Flow

GitHub Flow — это легкий рабочий процесс на основе ветвей. Он подчеркивает важность CR и помогает нам понять модель разработки CR, но не отвечает на вопросы развертывания, среды, выпуска, интеграции и т. д.

GitLab Flow

GitLab Flow не имеет таких очевидных спецификаций, как Git Flow и GitHub Flow, это скорее практика, основанная на GitHub Flow и всесторонне рассматривающая такие вопросы, как развертывание среды и управление проектами.

На основе среды:

Согласно графику выпуска:

Trunk-based Flow

Подобно GitLab Flow, основанному на плане выпуска, существует магистральная ветвь, которая принимает коммиты от всех разработчиков и обеспечивает ключевую поддержку для последующего CI/CD.

Согласно официальному описанию документа: «Вы можете отправить код напрямую в основную ветку (подходит для небольших команд) или использовать метод Pull-Request, если функциональная ветка не может существовать длительное время и продукт существует независимо. (продукт одного человека.)», отправка магистральной ветки относительно произвольна (не обязательно развертываемая), но она также должна пройти CR, вы можете использовать слияние в форме Fast-forward, чтобы убедиться, что Магистраль — это линия, и в подходящий момент времени проверьте релиз- * Филиал, чтобы выполнить официальную онлайн-операцию.

Как только выяснится, что для ветки релиза требуется исправление, разработка исправления будет сначала выполняться в ветке магистрали. релиз-* и может быть включен в следующий релизный цикл. .

Aone Flow

Согласно описанию сообщества разработчиков Alibaba Cloud: Aone Flow «Основной игровой процесс заключается в том, чтобы соотнести каждую ветку выпуска с определенной средой, например, ветка выпуска/тестирования соответствует тестовой среде развертывания, а ветка выпуска/производства соответствует в формальную онлайн-среду». Этот тип выпуска Этот метод может гарантировать, что каждая функция будет протестирована, но он не может гарантировать, что функции, переданные ЭК выпуска/тестирования, также могут быть переданы в среду выпуска/производства (комбинация функций выбор разный).

«Геймплей расширенной точки заключается в том, чтобы сопоставить ветку выпуска с несколькими средами, например, объединить выпуск в градациях серого и официальный выпуск, а также добавить шаги ручного принятия в середине». Суть в том, чтобы изменить «выпуск/тест» и «выпуск/производство» в базовом игровом процессе на «выпуск/объединение-функция» и исправить комбинацию выбора функций, чтобы обеспечить согласованность функций в каждом тесте среды.

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

практика компании

Все веб-службы ByteDance работают в частном облаке CE (Compute Engine), а продукты развертывания распространяются с помощью единой платформы компиляции кода, выпуска и управления версиями.Каждый продукт сборки управляется AR (репозиторий артефактов).

Статус развертывания в нескольких средах

перспектива сервера

Микросервис на стороне сервера работает на CE, а компиляция кода выполняется AR. CE и AR находятся в отношениях 1: N. Работа приложения зависит от нескольких AR. При управлении средой CE должен различать его. .

С точки зрения CE компании имеют 5 типов сред (в качестве примера возьмем отечественные продукты):

Через заголовки-H 'x-env-tag:{env}'Направляйте трафик в разные среды, чтобы выполнить требования к тестированию «тестирование разработки», «тест QA», «тест перед выпуском», «тест небольшого трафика» и «полный запуск».

Пример службы тестовой среды CE:

Внешний вид

Существуют различия между внешним интерфейсом и сервером. Ресурсы, к которым обращается URL-адрес, обычно создаются AR. Пути URL-адресов и AR находятся в отношениях N: 1, поэтому внешнее развертывание использует версию AR для различать окружение:

Интерфейсное развертывание может генерировать независимые доменные имена для среды тестирования и среды предварительного просмотра продукта для тестирования или устанавливать заголовки.-H 'x-env-tag:{env}'Провести экологическую диверсию.

Рабочие процессы Git, отработанные командами

В сочетании с текущей ситуацией во внешней и внутренней средах можно выделить три типа процессов НИОКР:

1. Процесс функционального тестирования (тестовая среда)

2. Процесс тестирования QA (тестовая среда)

3. Процесс онлайн-релиза (тестирование, предварительный выпуск, оттенки серого, онлайн-среда)

В настоящее время в компании есть три рабочих процесса Git, которые ему соответствуют:

• Работает в маленьких шагах: один ствол

• Выданный цикл: двойное сухое

• Периодический выпуск: три ствола

Сравнивая «Двойной магистраль» и «Один магистраль»,

Связаны:

1. Итеративная ветвь в состоянии MR ≈≈ R&D ствол Dev

2. Single Trunk Master ≈≈ Release Trunk Master

Есть и отличия:

1. Одномагистральная «ветвь исследований и разработок» не имеет фиксированной тестовой среды (по сравнению с двухмагистральной веткой разработки).
2. Когда несколько фич отправляются в тестовую среду одновременно, их нужно объединить в новую ветку, что неудобно в управлении
3. Разница конвейера CI в состоянии MR/non-MR с итеративной ветвью с одной магистралью

Практика одного ствола

Интерфейсная платформа управления микросервисами

Интерфейсная микросервисная платформа byte — это зрелый бизнес, для которого требуется лишь небольшая разработка функций/исправлений, а в рабочем процессе используется одномагистральный режим.

После локального тестирования он больше не проверяется в функциональной среде тестирования. Инициируйте запрос слияния, и после того, как CR пройдет комбинацию кода, перейдите в тестовую тестовую среду для тестирования. Если проблемы найдены, откатитесь назад и введите следующий раунд CR.

Несмотря на то, что незначительные изменения оказывают незначительное влияние, отсутствие процесса входа в среду функционального тестирования по-прежнему таит в себе скрытые опасности, которые могут повлиять на использование среды тестирования бизнес-сторонами, что не является хорошей практикой.

Единая магистраль подходит только для проектов с малым масштабом бизнеса и высокой зрелостью без серьезных изменений. Однако, независимо от масштаба бизнеса, его необходимо проверить в автономной среде перед выполнением процесса онлайн-релиза.

Практика двойного ствола

Частная облачная платформа

Рабочий процесс Git облачной платформы — это процесс от сложного к простому. Изначально для каждой среды развертывания существует ветвь развертывания. Точка фиксации функциональной ветви должна быть объединена с ветвями развертывания трех сред, что не может достичь цели последовательного тестирования.

После усовершенствования стандартный магистральный поток по-прежнему может соответствовать требованиям к развертыванию в онлайн-средах/песочнице/boe.

В облачной платформе сотни бизнес-партий участвуют в облачной платформе (похоже на облачную платформу ALIBABA). Хотя на рисунке показаны только три среды, пять сред фактически используются в ежедневном развитии.

Бизнес на Тайване

Рабочий процесс Git в бизнес-центре фокусируется на проблемах, возникающих при совместной разработке одного и того же проекта несколькими людьми:

1. Несколько функций тестируются независимо друг от друга, и при объединении кода возникает много конфликтов, которые могут привести к онлайн-ошибкам.
2. До и во время теста, если мастер обновлен, он может не синхронизироваться по времени.Слияние с мастером перед выходом в онлайн может вызвать конфликты или ошибки
3. С точки зрения дизайна процесса master используется как релизная ветвь, а релиз-* — как тестовая ветвь, которая сочетает в себе удобство одного транка (исправление напрямую взаимодействует с мастером) и управление функциями двойного транка.
4. В отличие от магистрального потока, основная ветвь — это релизная ветвь, а тестовая ветвь — краткосрочная.
5. Еще одна особенность заключается в том, что в процессе тестирования выпуска, если в какой-либо функции обнаруживается ошибка, она извлекается непосредственно из ветки выпуска для исправления, а затем снова объединяется с выпуском.

Спецификация рабочего процесса Юпитера

Jupiter — это движок байтовой веб-разработки, охватывающий такие области разработки интерфейса, как веб, библиотека компонентов, BFF, SSR и т. д. Jupiter рекомендует Flow, аналогичный Flow на основе магистрали, и с точки зрения CI/CD дает рекомендации по работе с Git при разработке новых требований, исправлений и т. д.

1. Существуют согласованные процессы и шаблоны между проектами с дублирующимся персоналом, чтобы избежать увеличения когнитивной нагрузки, избегая путаницы и путаницы, когда один и тот же человек переключается между разными проектами и может сосредоточиться на практике и улучшении, обмене опытом и инфраструктурой.
2. Онлайн-ритм должен быть гибким. Забота как о проектах на ранней стадии, так и о крупномасштабных проектах, учитывая, что частота запуска проектов будет меняться, когда они достигают разных этапов. Таким образом, можно выходить в сеть раз в неделю, раз в день (подходит для проектов с большим количеством людей и высокими требованиями к стабильности), а также запускать несколько функций несколько раз в день. Любой может инициировать онлайн-запуск в любое время.
3. Поддерживается монорепозиторий. Проекты, в которых участвуют разные люди в разных направлениях, могут совместно использовать хранилище для облегчения повторного использования кода и инфраструктуры. Поэтому разные проекты на складе могут иметь разные онлайн-ритмы и онлайн-требования.
4. Поощряйте непрерывную интеграцию (CI), интеграция — это не то же самое, что развертывание, нет необходимости подчеркивать, когда будет выпущен код интеграции MR, и он не будет запущен без ведома. Непрерывное развертывание (CD) также приветствуется.Развертывание не равно выпуску, и код, который не может быть выпущен, имеет возможность быть отключенным до его официального запуска.
5. Онлайн-процесс должен быть фиксированным, повторяющимся, способным к единообразному совершенствованию и постепенному увеличению автоматизации.Невозможно повторно, временно спланировать или изменить онлайн-метод каждый раз, когда он выходит в онлайн, что увеличивает нагрузку и стоимость.
6. CI является предпосылкой CD.Модификации без CI не могут войти в ссылку CD.
7. Никакие модификации не могут быть внесены непосредственно в режиме онлайн без промежуточного (предрелизного, максимально согласованного онлайн) тестирования.
8. История КИ и КД должна быть абсолютно достоверной и прослеживаемой, и ее можно только добавлять, а не вычитать и изменять.
9. Максимально сведите к минимуму ручные операции и избегайте онлайн-операций на конкретных персональных машинах.

Три основные практики

Приложение миллиардного уровня

Версия приложений должна быть безусловно, самым комплекс сценариев управления филиалом. Как только пакет установки клиента доставляется на пользовательские каналы, загружено, если вы не можете обновить исправления нагревом, он серьезно повлияет на приложение для сохраненного пользователя.

Версия закона, созданная приложением, сделала более стандартизированную версию, переключение функций важно, когда мы чувствуем, когда проблемы с CR, CI / CD, по сравнению с влиянием на онлайн-разработку миллиона пользователей функции приложения, не ощущается. сделать Web-CI/CD простым слишком много?

Суммировать

В этой статье описывается использование рабочего процесса Git с самых разных сторон, и я надеюсь, что она будет полезна всем. Рабочий процесс Git должен гарантировать запуск, и полное тестирование необходимо в процессе запуска.Хороший рабочий процесс Git может гарантировать, что тестирование будет постепенным и надежным. Сочетание управления средой и рабочего процесса Git также сформировало множество спецификаций в Toutiao, включая «развертывание среды», «планирование трафика», «тест подключения» и другие спецификации использования; «разрешена ограниченная сцена», «разрешена временная сцена», «ограниченные ограничения окружающей среды, такие как «Разрешенный процесс». В сочетании с CI/CD мы можем гарантировать быструю итерацию и безопасный запуск бизнеса по всей цепочке.

использованная литература

1. Trunk-based Development vs. Git Flow

2. Please stop recommending Git Flow!

3. Understanding the GitHub flow

4. Introduction to GitLab Flow

5. cn.trunkbaseddevelopment.com

6. В Али, как мы управляем ветками кода?

7. Управление кодом Google

Добро пожаловать в "Byte Front End"

Контактный адрес электронной почты для доставки резюме "tech@bytedance.com"