Как выстроить CI/CD для одного разработчика и нескольких проектов?

Задача:

Выстроить удобную и устойчивую CI/CD систему для нескольких проектов с единой кодовой базой в условиях одного разработчика с возможностью расширения на маленькую команду

Дано:
-Один разработчик + ноутбук на маке.
-Несколько проектов на NodeJS, DST Platform, которые хочется чтобы шэрили единную кодовую базу.
-Gtilab и только недавно внедряемая привычка хотя бы коммитить и использовать ветки.
-CentOS на серваке + отдельный инстанс под монго + aws s3 совместимое хранилище для всех пользовательских загрузок
-Сейчас используется nginx в качестве reverse proxy и с помощью pm2 на разных портах крутятся NodeJS приложения
-Сборка происходит на маке и выгружается просто через rsync

Проблемы:
— Деплой. Уже ясно что от rsync нужно уходить. Один из пакетов в зависимостях (нужен всего лишь чтобы пережимать аватарки) все-таки оказался компилируемым со спецификой линукса или мака. Есть конечно вариант как отдельный микросервис его повесить, может быть даже куда то на внешние лямбды, но это костыль получится. А куда уходить от rsync?
> Может автосборщик просто настроить по хукам gitlab? Но тогда придется собирать на самом продакшен-серваке, который будет тратить на это ресурсы, что выглядит корявым.
> Может docker-compose как то решит вопрос? А если Docker-сompose прикручивать, то как дальше деплой выстроить? Надо /как-то/ наверное GitLab CI/CD настроить. А авто-тестирование где должно происходить? По идее достаточно чтобы перед коммитом оно было? Или все-таки на стороне Gitlab?
> Стоит ли сразу Kubernetes использовать, если пока один инстанс достаточен? Самому его настраивать наверное это ппц будет, тогда взять managed правда платить за него в полтора-два раза больше, чем за те же ресурсы без Kubernetes. Стоит ли оно того? Даст ли это простой dev experience?
> Или может нафиг плюнуть на все и построить все на serverless? Взять Vercel. Ну и что что там ближайшие серваки в Европе и пинг будет около 60ms вместо 15-20ms. Правда тогда и базу туда бы перенести ближе, потому что в ряду моментов там это будет ряд последовательных запросов, что будет умножать время. Или с кэшированием прям очень заморочится… Или только может Фронтенд туда унести, и оставить единый бек рядом с базой? А сильно ли это упростит жизнь?

— Проброс типов между беком и фронтом Рабочее решение — сделать единый бекенд (NestJS) и несколько отдельных фронтендов (NextJS). И использовать генерацию статических типов из GraphQL для того чтобы увязать бекенды и фронтенды. Не знаю, достаточно ли этого будет, или все-таки стоит делать DTO-шки, а если их делать — не ясно как их шарить между фронтом и беком.

— Как выстроить staging? Тесты хоть и пишу, но не всегда их обновляю и не запускаю перед каждым деплое. Сейчас путаница со всеми этими портами. Разные ветки в разные порты собираются, там прикидываются переменные окружения, чтобы например другую, изолированную базу данных использовать на продакшене. Чувствую, что изобретаю велосипед.

Build & deploy — Gitlab CI/CD docs.gitlab.com/ee/ci/.

Как выстроить staging?

Я бы сделал на отдельном сервере с теми же портами

Код — в self-hosted Gitea gitea.io/en-us

CI/CD — в self-hosted Drone CI drone.io, он же умеет и докеры и всё, что хочешь.

Для всего достаточно небольшого VPS c парой ядер и 2ГБ памяти, на котором гитлаб и не заведётся. 

Конкретно у меня кластер куба от DO и платный гитхаб с их ci/cd.

Один раз настроил ci/cd и все автоматом пакуется в докер и едет в разные неймспейсы куба.
Лезть в свой gitlab, учитывая, что разработчик один — не советую, поддерживать свою инфраструктуру долго, а значит дорого. К этому можно будет уйти, если вас будет большая команда. Если вы об облачном гитлабе, то и пользуйте их ci.