Обзор кода — неотъемлемая часть всех ваших проектов по разработке программного обеспечения. Но иногда ваша организация следует неэффективному PR-процессу, применяя одни и те же наборы политик к каждому запросу на включение или слияние, независимо от изменения. Это может увеличить время от внесения изменений до выпуска их в производство. Время цикла ваших команд также сильно пострадает, и ваши разработчики будут разочарованы.
Но постоянно появляются новые методы, чтобы сделать жизненный цикл PR более плавным 😉. Они часто сочетают автоматизацию и взаимодействие с человеком, чтобы сократить время на слияние. В этой статье вы узнаете о некоторых новых инструментах, которые помогают автоматизировать ваш рабочий процесс, включая GitHub Actions, владельцев кода и собственный gitStream от LinearB.
Что такое действия GitHub?
GitHub Actions — это платформа CI/CD, позволяющая создавать пайплайны для автоматизации процессов сборки. Действия похожи на методы, которые вы будете использовать при программировании и выполнении задач в репозитории. Действия GitHub могут поддерживать процесс слияния, но их нужно настроить самостоятельно. Если вы не можете найти уже существующее действие для выполнения нужного действия, вам нужно создать его с нуля или найти пример с открытым исходным кодом.
Хотя аспект автоматизации этого инструмента можно приравнять к большей эффективности, действия по умолчанию работают на уровне репозитория и не обеспечивают детального контроля без большого количества узкоспециализированной работы в YAML. Это означает, что на настройку и обслуживание может уйти довольно много времени. Процесс автоматизации также может позволить автоматически объединять некачественный код без одобрения мерж-реквеста. GitHub Actions ограничен GitHub и не так универсален, как Code Owners — дальше вы узнаете почему.
Кто такие владельцы кода?
Владельцы кода — это функция в системах контроля версий, таких как Git, которая позволяет пользователям назначать права собственности на определенные файлы или каталоги. Это гарантирует, что назначенные владельцы просматривают изменения перед их слиянием с кодовой базой. Вы также можете использовать владельцев кода для автоматизации рабочих процессов, например для отправки уведомлений владельцам при внесении изменений. Он обычно используется в проектах с открытым исходным кодом для управления вкладами внешних участников.
Функция владельцев кода была впервые представлена GitHub в 2017 году. Хотя GitHub не изобретал концепцию владельцев кода, он популяризировал ее, интегрировав в свою платформу и сделав ее более доступной для разработчиков. С тех пор принятие владельцев кода стало довольно распространенным явлением, особенно среди разработчиков, использующих системы контроля версий на основе Git, такие как GitHub, GitLab и Bitbucket. Все эти платформы поддерживают владельцев кода в той или иной форме, позволяя пользователям назначать права собственности на код и автоматизировать рабочие процессы.
Владельцы кода GitHub
В GitHub владельцы кода позволяют настроить владельцев кода репозитория с помощью файла с именем CODEOWNERS. Это поможет вам убедиться, что нужные люди просматривают код, который им наиболее интересен.
Вы можете настроить репозиторий только для разрешения объединения кода после утверждения владельцем по умолчанию. Вы даже можете разбить его дальше, чтобы определенные файлы требовали одобрения владельца кода, в то время как любой мог утвердить другие.
Использование файла GitHub CODEOWNERS снижает риск объединения изменений без одобрения владельцев кода, что повышает общее качество кода. Но это может снизить эффективность, особенно если этим конкретным разработчикам необходимо просмотреть множество изменений.
Например, когда Symphony Talent обратилась к владельцам кода, они в конечном итоге оказались в ситуации, когда восемь старших разработчиков все должны были просмотреть все PR. Каждый из них получал десятки PR в день, и управлять всем этим без права собственности было невозможно. Не зная, кто что должен проверять, это создало узкое место. С помощью gitStream они теперь могут назначать рецензента на основе команды авторов PR, и в каждой команде есть старший рецензент.
Владельцы кода GitLab
Как и в GitHub, с владельцами кода GitLab вы можете определить, кто разрабатывает и поддерживает функцию, а также владеет результирующими файлами или каталогами в репозитории. Используя файл CODEOWNERS, вы можете убедиться, что запросы на слияние одобрены владельцами кода перед слиянием, или даже защитить определенную ветку, разрешив только владельцам кода утверждать изменения в ветке.
Вы также можете использовать GitLab Code Owners и утверждающих (с правилами утверждения) для создания более гибкого рабочего процесса. Это требует от вас:
- Используйте владельцев кода, чтобы определить пользователей, обладающих знаниями в предметной области для определенных путей в вашем репозитории.
- Используйте утверждающих и правила утверждения для определения областей знаний (например, группы безопасности), которые не привязаны к конкретным путям к файлам в вашем репозитории.
Посмотрите это видео о владельцах кода в GitLab для получения дополнительной информации:
Пример файла CODEOWNERS
Создайте новый файл CODEOWNERS в корне той ветки, куда вы хотите добавить владельцев кода.
# This is a comment. # Each line is a file pattern followed by one or more owners. # These owners will be the default owners for everything in # the repo. Unless a later match takes precedence # @global-owner1 and @global-owner2 will be requested for # review when someone opens a pull request. * @global-owner1 @global-owner2 # Order is important; the last matching pattern takes the most # precedence. When someone opens a pull request that only # modifies JS files, only @js-owner and not the global # owner(s) will be requested for a review. *.js @js-owner #This is an inline comment. # In this example, @doctocat owns any files in the build/logs # directory at the root of the repository and any of its # subdirectories. /build/logs/ @doctocat # The `docs/*` pattern will match files like # `docs/getting-started.md` but not further nested files like # `docs/build-app/troubleshooting.md`. docs/* [email protected] # In this example, @octocat owns any file in an apps directory # anywhere in your repository. apps/ @octocat
Что такое gitStream?
gitStream — это механизм динамических правил, который позволяет вам определять условия и результаты PR. С его помощью вы можете реализовать такое же поведение владельцев кода. Разница в том, что вы можете добавить больше условий, не только на основе шаблонов пути к файлу, и вы можете использовать динамические данные.
Например, вы можете назначить рецензента на основе кто написал PR и других условий, таких как путь к файлу. Вы также можете назначить рецензента на основе динамического анализа истории системы контроля версий кода, например, «rankByGitBlame» и т. д.
Например, eMed использует gitStream в репозитории, содержащем двоичные ресурсы и файлы JSON для поддержки своих сценариев процедур. Некоторые из этих процедур уже запущены в производство, но многие из них являются строго внутренними тестовыми данными или активами, находящимися в разработке, недоступными для клиентов.
Им нужна была система, в которой живые производственные активы и процедуры должным образом проверялись бы разными людьми (клиническими, юридическими, UX и дизайнерами и т. д.), но ресурсы для разработки и тестирования можно было бы использовать свободно.
Они даже хотели автоматически утверждать производственные процедуры, если изменения касались строго формата, без какого-либо существенного содержания. Им никогда не удавалось добиться такой сложности с помощью владельцев кода, но с gitStream это прекрасно работает! 🙂
Хотите узнать, как внедрить индивидуальную автоматизацию рабочего процесса разработки, чтобы сократить время проверки кода до 40 %? Посмотрите этот практический семинар, чтобы настроить бесплатный инструмент gitStream для автоматической:
✅ Классифицировать и направлять запросы на вытягивание
✅ Добавлять расчетное время проверки в PR
✅ Применять настраиваемые правила
Ведущий специалист по продукту gitStream, Офер Афиас, проведет вам живую демонстрацию трех основных функций при начале работы с автоматизацией рабочего процесса gitStream, чтобы эффективно масштабировать вашу команду и улучшить опыт разработчиков.
gitStream против владельцев кода против действий Git
При выборе инструмента автоматизации рабочего процесса для вашей команды необходимо учитывать четыре наиболее важных фактора: 1) масштабируемость инструмента, 2) риск, 3) эффективность и 4) настраиваемость. Эти факторы влияют на способность инструмента справляться с растущими рабочими нагрузками, минимизировать потенциальные проблемы, оптимизировать производительность и соответствовать уникальным требованиям разработки.
Без согласования этих четырех факторов ваши команды не смогут добиться успеха. Итак, мы проанализировали каждый инструмент по этим ключевым факторам, чтобы помочь вам!
1. Масштабируемость
Использование владельцев кода Git является наименее масштабируемым подходом, поскольку разработчикам по-прежнему необходимо выполнять проверку кода вручную перед слиянием кода. Если одному и тому же человеку приходится просматривать множество запросов на вытягивание, процесс может стать огромным узким местом, пока владелец кода пытается наверстать упущенное.
Действия gitStream и GitHub значительно лучше масштабируются. Они оба автоматизируют процесс слияния и могут предотвратить ненужные ручные проверки тривиальных изменений. gitStream может даже автоматизировать процесс выбора рецензента на основе нескольких критериев, которые не требуют редактирования при добавлении новых членов команды!
2. Риск
GitHub Actions масштабируемы, но рискованны, поскольку позволяют объединять даже некачественные изменения кода. Напротив, владельцы Git-кода не позволяют коду выполняться без одобрения мерж-реквеста от конкретных людей, так что это низкий риск. Но это происходит за счет сложности масштабирования.
Когда дело доходит до риска, gitStream превосходит два других метода. Он предоставляет более сложный набор правил для определения того, какие изменения могут быть утверждены автоматически, какие требуют утверждения владельцами кода, а какие требуют нескольких рецензентов.
3. Эффективность
Использование владельцев кода Git — не лучший вариант, если вам нужна эффективность. Владельцы кода могут увязнуть в трудоемких проверках активных баз кода. Действия GitHub эффективны и имеют возможности автоматизации, но их высокий риск означает, что вашим командам придется иметь дело с растущим числом ошибок, что снижает их общую эффективность.
GitHub Action также является низкоуровневой операцией, требующей усилий для кодирования, тестирования и обслуживания. gitStream, с другой стороны, является системой более высокого уровня, которая позволяет очень легко применять многие правила автоматизации. Опять же, gitStream предлагает значительные преимущества по сравнению с другими методами. Это гарантирует, что ваши команды не тратят время на низкоуровневые проверки, а также устраняет риски ошибок.
4. Настройка
Все три варианта обеспечивают определенный уровень настройки, например определение владельцев кода и указание того, какие изменения могут быть автоматически объединены. Но владельцы кода позволяют вам только выбирать, кто является рецензентом и какие файлы важны. И хотя вы можете в некоторой степени настроить действия GitHub, они ограничены определенной областью.
gitStream предоставляет больше возможностей, эффективно предлагая функциональные возможности как GitHub Actions, так и владельцев кода, а затем и некоторые другие. gitStream построен на основе GitHub Actions и имеет с ними некоторые сходства. Но gitStream дает вам гораздо больше возможностей и детализации вплоть до уровня файла, который соответствует регулярному выражению, а не влияет на весь репозиторий. gitStream также бесплатен и может быть реализован намного быстрее и динамичнее, чем GitHub Actions.
Бонусный раунд
gitStream обеспечивает те же возможности, что и использование GitHub Code Owners, а также позволяет включать дополнительные условия, чтобы лучше соответствовать меняющимся требованиям вашей команды.
Инструмент также предлагает более широкий спектр вариантов использования. Например, он позволяет автоматизировать более сложные рабочие процессы Git, такие как автоматическая маркировка запросов на вытягивание, отправка уведомлений внешним инструментам или системам и маршрутизация запросов на включение на основе нескольких критериев. Это позволяет вашим командам оптимизировать свои рабочие процессы Git, чтобы лучше соответствовать их конкретным процессам и требованиям разработки.
Чтобы помочь вам принять решение быстрее, ознакомьтесь с приведенной ниже таблицей, в которой кратко описывается ранжирование каждого инструмента:
Когда использовать каждый инструмент
Каждый инструмент автоматизации рабочего процесса имеет свои сильные и слабые стороны, но все они могут служить определенной цели в определенном контексте. Чтобы помочь вам, мы выделили три сценария, в которых вы можете выбрать любой из трех инструментов, в зависимости от размера и масштаба проектов вашей команды.
1. Несложные проекты с GitHub Actions
GitHub Actions отлично подходят для динамичных и несложных проектов. Поскольку GitHub Actions позволяет выполнять быстрое слияние, повышенная скорость, вероятно, перевесит риск. GitHub Actions может помочь вам ускорить проекты, когда качество не является вашей основной задачей. Так что это хорошо работает, когда у вас есть небольшая команда, работающая над довольно простым проектом.
Тем не менее, GitHub Actions не идеальны для крупных проектов с более важными и сложными элементами. Хотя GitHub Actions может помочь вам быстрее продвигаться по проекту, они не идеальны, когда об ошибках не может быть и речи. Первоначальный прирост скорости, обеспечиваемый этим инструментом, обязательно приведет к ошибкам взлома кода, которые могут остановить ваш прогресс.
2. Владельцы кода для небольших кодовых баз
Владельцы кода предлагают подход к слиянию кода с низким уровнем риска и низкой скоростью. Это делает владельцев кода полезным подходом для небольших проектов без сжатых сроков. Файл CODEOWNERS также хорош для проектов без строго регулируемых и проверенных приложений, где даже самая маленькая ошибка может привести к катастрофическим последствиям.
Владельцы кода также не подходят для больших кодовых баз с частыми изменениями, так как владельцы кода могут быстро перегрузиться обзорами. Владельцы кода могут помочь обеспечить качество кода вашей команды, но за это приходится платить — скоростью.
3. Оптимизируйте корпоративные приложения с несколькими кодовыми базами с помощью gitStream
gitStream оптимизирован для проектов любого размера с любым количеством разработчиков. Он обеспечивает оптимальное сочетание автоматизированного слияния и проверки кода человеком в зависимости от контекста изменения. Это делает gitStream применимым к большинству реальных случаев использования, особенно если у вас есть большая команда инженеров с несколькими репозиториями, каждый из которых имеет разных владельцев и специалистов.
gitStream обеспечивает быстрое слияние кода, а также поддерживает качество, чтобы вы могли безопасно сократить время цикла. В качестве бонуса gitStream помогает устранить самые большие узкие места, с которыми часто сталкиваются команды разработчиков: медленные циклы PR. Таким образом, gitStream не только ускоряет ваши процессы при сохранении качества, но и повышает моральный дух разработчиков и уменьшает их разочарование.
Сделайте свой шаг на слиянии
Стандартизация вашего процесса проверки PR с помощью политики как кода важна, потому что время, необходимое для слияния, может привести к задержкам с исправлением ошибок, выпуском функций и общим временем цикла ваших команд. Также очень важно не вызывать беспокойства у разработчиков, потому что они не могут выполнять какую-либо работу из-за постоянного переключения контекста.
Если вы хотите увеличить частоту слияний, GitHub Actions и владельцы кода могут быть хорошими вариантами. Но вам нужно помнить о размере ваших проектов и склонности к риску, чтобы не жертвовать качеством ради скорости и наоборот.
С другой стороны, gitStream помогает вашим командам создавать динамические правила владельца кода, чтобы вы могли непрерывно объединяться, сохраняя при этом высокое качество кода. Этот инструмент знаменует собой переход от универсальной процедуры для всех запросов на вытягивание, которая замедляет время слияния и негативно влияет на время цикла.
gitStream также позволяет вашим командам выходить за рамки этих жестких требований, определяя необходимую глубину проверки и назначая рецензентов в зависимости от того, кто лучше всего подходит. Поскольку gitStream может беспрепятственно обрабатывать проекты разного размера и является бесплатным, это отличный вариант для большинства реальных бизнес-проектов.
Первоначально опубликовано на https://linearb.io 21 декабря 2022 г.
