Конфигурация с одним CI для нескольких репозиториев

Question

ищет совета по поводу такой проблемы.

У нас есть стек микросервисов, написанных на NodeJ и работающих в кластере Kubernetes.У нас есть отдельный репозиторий GitHub для каждого из них, и в настоящее время мы используем Circleci для нашего процесса CI / CD.На данный момент у нас есть около 25-30 репозиториев, но их количество будет увеличиваться, и проблема, с которой мы столкнулись сейчас, заключается в том, что нам нужно иметь конфигурационный Circleci yaml в каждом репозитории, и если нам нужно что-то глобально изменить в нашем конвейере ci / cd, мыНеобходимо обновить это в каждом репозитории, что, очевидно, является довольно болезненным процессом, и Circleci не поддерживает наличие одного конфигурационного файла для нескольких репозиториев.

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

Answer 1

На мой взгляд, у вас есть 2 варианта - у вас может быть одно задание / конфигурация CI, в котором можно развернуть одну / несколько служб (если все службы одинаковы).Или, если каждый сервис отличается от вас, вам нужно отдельное задание / конфигурация для каждого.Если это где-то посередине, это вопрос о том, хотите ли вы одну работу, которая имеет кучу операторов if / then, например, «если repo = user, то сделайте эту особую вещь».До сих пор подход if / then работал хорошо для меня, но в конечном итоге было слишком много особых случаев, когда было проще просто использовать уникальную конфигурацию для каждой службы.

Я решил эту проблему«трудно сделать 1 строчку в 30 репозиториях git», имея суперпользователя git.По сути, обычные пользователи могут объединяться только с помощью PR, но суперпользователь может фиксировать напрямую.Поскольку я меняю только такие вещи, как конфигурационные файлы, редко возникают конфликты слияния или неработающие тестовые случаи, поэтому он работает.Вот пример кода:

#!/usr/bin/env bash

for dir in /temp/*/
do
    cd $dir

    git pull
    sed 's/Nick/John/g' report.txt > report_new.txt
    git commit -m "CI change" && git push

    cd ..
done

Answer 2

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

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

   Например: вам нужно будет создать инструмент CLI или скрипт для автоматизации копирования кругового файла и фиксации в соответствующих репозиториях (когда требуется изменение)

   PROS : изоляция - все репозитории имеют свою собственную конфигурацию, если вы когда-либо собираетесь использовать микросервис golang или другую конфигурацию в одной из ваших служб nodejs, изменение конвейера CI не будет проблемой

   CONS: немного дополнительной работы для автоматизации написания вокруг отдельного управления этой конфигурацией

2. Оптимизация для упрощения ремонтопригодность .Рисунок, как поделиться конфигурацией с одним конвейером в ваших репозиториях.

   Например: используйте подмодули git для хранения файла circle.yml или используйте отдельный пакет npm с файлом circle.yml.Другая альтернатива - использовать инструмент CI, который поддерживает шаблоны, затем определить шаблон конвейера и повторно использовать его для каждого отдельного конвейера (один из инструментов CI, который его поддерживает - Teamcity)

IЛично выбранный подход № 1 в аналогичной ситуации.ИМХО, это цена, которую нужно платить, когда решаешь пойти с микросервисами, чтобы не получить платформу, которая скорее является распределенным монолитом :) также мне очень понравилось, когда все репозитории являются описательными и самодостаточными, а конвейер CI как кододин из способов помочь достичь этого