Блог

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

Я хотел бы посмотреть, есть ли способ выполнять утверждения в git. Если есть решение, которое доступно только для github (на основе разветвления github и запросов на извлечение из forks, или обзоров кода github и т.д.), Это тоже было бы интересно.

Необходимы следующие конкретные элементы:

• Кто что-то одобрил, должно быть легко выяснить (git log) и доказуемо, способом, эквивалентным Docusign или электронной подписи. Например, сработало бы подписание с помощью ключа подписи кода.

• Возможно, потребуется одобрение каждого фрагмента кода более чем одним пользователем (может быть список для каждого проекта или на индивидуальной основе)

• Очень желательно иметь возможность утверждать больший набор изменений (запрос на извлечение, слияние ветвей и т.д.) Сразу, А не только за один коммит.

• Желательно, но не обязательно, иметь возможность предотвращать некоторые действия (слияние с мастером / создание тега выпуска и т.д.), Если не получены правильные утверждения.

Я знаю, что в git есть функция отключения от входа, можно ли это использовать для того, что я описал?

РЕДАКТИРОВАТЬ Спасибо за все ответы… С точки зрения некоторых из них, похоже, мне следует немного уточнить. Моя цель в основном состоит в том, чтобы легко собирать информацию о том, кто что когда одобрил (а также более подробную информацию из обзоров кода), а не автоматически применять политики (хотя это тоже неплохо). В этом случае все участники находятся в одной организации, и можно предположить, что им доверяют и что они (в целом) делают правильные вещи. Просто теперь процесс выполняется вручную, очень медленно и несколько подвержен ошибкам. Чтобы дать вам представление: для каждого запроса на извлечение мы создаем пару документов MS Word и помещаем их в Docusign для подписи…

PullApprove — это сервис, который позволяет блокировать запросы на извлечение до тех пор, пока они не будут рассмотрены и одобрены соответствующими людьми. Это работает только для репозиториев Github, но, похоже, удовлетворяет всем вашим требованиям. Утверждения PullApprove предоставляются путем оставления комментария в ветке комментариев, соответствующей запросу на извлечение, поэтому там будет оставлена запись.

Вы можете использовать защищенные ветви GitHub для достижения части этого:

Защищенная ветка:

• В него не могут быть внесены изменения, пока не пройдут требуемые проверки статуса
• Нельзя вносить в него изменения, пока не будут одобрены требуемые проверки

Настройте их в настройках репозитория в разделе ветви.

Но в GitHub нет прямого средства для подписания коммитов, и, к сожалению, нет ничего, что обеспечивало бы подпись коммитов.

Из того, что вы описываете, это звучит как пример использования рабочего процесса «диктатор и лейтенант»: https://git-scm.com/book/it/v2/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow

Этот рабочий процесс фактически используется Линусом Торвальдсом («диктатором») и его доверенными «лейтенантами» (сопровождающими подсистемы ядра) для реализации иерархической структуры проекта. Итак, как вы можете себе представить, это не относится конкретно к GitHub — оно основано исключительно на использовании нескольких форков проекта на git, каждый форк поддерживается одним ответственным за него человеком.

Вот как это будет работать с вашими требованиями:

• Кто что-то одобрил, зависит от того, у кого это есть в их форке. Если он у них есть, это означает, что они извлекли его и, следовательно, одобрили.

• Для нескольких утверждений (уровней иерархии) первый утверждающий извлекает его и публикует в своем форке; затем следующий утверждающий извлекает из форка первого утверждающего и публикует в своем форке; и так далее.

• Этот метод в основном используется с запросами на извлечение (т. Е. ветвлениями), поэтому этот момент учитывается автоматически.

• Вы бы, по соглашению, «благословили» репозиторий dictator в качестве «главного» или канонического репозитория, и все, что там есть, автоматически считалось бы прошедшим все необходимые утверждения. Благословенный сопровождающий репозитория извлекал данные только из репозиториев лейтенантов и ни из чьих других, таким образом, автоматически применяя процесс утверждения.

Я настоятельно рекомендую вам записать это карандашом с людьми (или ролями), которых вы имеете в виду; просто создайте мысленную ассоциацию, что один человек соответствует одному форку репозитория.

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

• Во-первых, все люди, ответственные за утверждение документов, должны настроить подписи GPG для всех своих коммитов. В идеале это должны делать все в команде. Это не означает, что члены команды «подписываются», когда они совершают коммит, просто они подписывают каждый сделанный ими коммит.
• Сохраняйте CHANGELOG.md файл в корне репозитория, соответствующий перечисленным здесь соглашениям:https://keepachangelog.com/en/1.0.0 /.
• Перед выпуском каждого выпуска CHANGELOG.md запись для этого выпуска подготовлена в Unreleased разделе.

• В дополнение к разделам, которые рекомендует keepachangelog ( Added , Changed Deprecated и т.д.), добавьте Signed раздел. В этом разделе должен быть шаблон со списком пользователей, которым необходимо подписать релиз, и с какой ролью они подписываются. Например:

   ### Signed
  
  | Role           | Team Member      | Signed |
  | :------------- | :----------      | :----- |
  | Product Owner  | Joe Placeholder  |        |
  | Technical Lead | Jane Example     |        |
  ...
    

• Перед выпуском каждый из людей, перечисленных в разделе «Подписано», просматривает релиз и, когда они довольны, добавляет свои инициалы в Signed столбец. Например.:

   ### Signed
  | Role           | Team Member      | Signed |
  | :------------- | :----------      | :----- |
  | Product Owner  | Joe Placeholder  |        |
  | Technical Lead | Jane Example     | JE     |
  …
    

• Инициалы на самом деле ничего не доказывают, но предоставляют быстрый читаемый человеком контрольный список того, кто подписал и не подписал релиз. Однако участник команды, который добавил свои инициалы, затем фиксирует свои изменения в CHANGELOG.md с сообщением о фиксации Sign off release vX.X.X . Поскольку каждый коммит подписывается с помощью GPG, это криптографическое доказательство того, что подписавший действительно подписал релиз.

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

Итак, вот как мы будем реализовывать этот процесс. Вот несколько способов сделать это, которые я также рассмотрел:

• Очевидный вариант — использовать запросы на извлечение из Github / Gitlab и защищенные ветви, чтобы предотвратить слияние с master или «выпущенную» ветку без проверки.

  • Плюсы:
    • рабочий процесс, который разработчики уже понимают,
    • хорошо поддерживается такими инструментами, как Github.
    • такие инструменты, как LGTM, могут помочь, когда требуется многократный выход
  • Минусы:
    • Не переносится за пределы Github или Gitlab, если вы решите сменить инструменты Git.
    • Невозможно выполнить криптографическую подпись с использованием ключа GPG, хотя вход в Github является эквивалентной формой доказательства.
    • Не ясно, в каком качестве кто-то подписывается (например Product Lead ) без дополнительной работы / обозначения. Это нормативное требование в моей области.
    • Трудно понять, кто подписался, а кто нет, без долгой прокрутки комментариев к запросу на извлечение вверх и вниз.

• Я также рассмотрел возможность использования инструмента GitHub Releases вместо CHANGELOG.md для записи заметок о выпуске и подписей пользователей, но нет способа предоставить подтверждение подписи. Также не переносим за пределы Github.

• Использование рабочего процесса «диктатор и лейтенант», упомянутого @Yawar. Это хорошо выглядит для проектов с открытым исходным кодом, но при работе в частных репозиториях Github не допускает нескольких форков одного и того же репозитория. Следовательно, это невозможно реализовать, если вы используете частные репозитории Github. Возможно, было бы возможно реализовать нечто подобное, имея несколько ветвей в одном репозитории с разными «помощниками», ответственными за каждую ветвь. Затем эти «помощники» завершают работу, принимая запросы на извлечение от своих подгрупп в свою ветку, прежде чем отправлять запросы на извлечение в ветку «диктатора». Однако: экспериментируя со сложными ветвящимися рабочими процессами, такими как Git Flow в прошлом, было очень сложно реализовать гладко, и поэтому я бы очень скептически отнесся к внедрению рабочего процесса, более сложного, чем интеграция всех запросов на извлечение в одну Master ветку.