В GitHub обновите одну ветку, чтобы она соответствовала другой.

Question

Итак, вот в чем дело: для каждого из 50+ наших репозиториев у нас есть трехуровневая модель ветвей: Dev, Test, Master.Dev может обновляться всякий раз, когда этого требуют разработчики, а изменения агрегируются руководителем группы и передаются для развертывания в нашу тестовую среду, когда код объединяется с тестовой веткой и маркируется.Как только код протестирован и передан (и развернут), он переносится в master.После того, как код находится в master и успешно развернут, мы убиваем старые ветви и создаем новые только по запросу.

Но мы сканируем наш код с помощью SonarQube и Fortify, и обновляется наше расписание сканирования каждый раз, когда запрашивается новая ветвь.Мы хотим сохранить модель обновления веток в каждом выпуске.

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

Мы могли бы запустить его как часть наших конвейерных сценариев Jenkins, но это просто переместило бы проблему с «обновления ветвей в расписаниях сканирования» на «обновление более 50 сценариев» (или одного параметризованного списка, которыйлучше, но не идеально)

Есть ли способ автоматического выполнения слияния из ветви dev в постоянную тестовую ветку одновременно с первичным слиянием с непостоянной первичной тестовой веткой?Все без необходимости заходить и обновлять сценарии вручную (или, лучше, параметризованный список)?Могу ли я столкнуться с проблемами (проблемами родительской ветви и т. Д.?)

Answer 1

Как правило, требуемое поведение здесь выполняется на стороне сервера, и есть несколько способов сделать это.

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

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

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

В-четвертых, если вы используете GitHub (облачная версия, а не собственная), вы можетевозможность подписаться на действия GitHub и использовать его для выполнения этой задачи.Для этого также потребуется какой-то секрет, который можно использовать для обновления ветки.