Задача:
Выстроить удобную и устойчивую 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? Тесты хоть и пишу, но не всегда их обновляю и не запускаю перед каждым деплое. Сейчас путаница со всеми этими портами. Разные ветки в разные порты собираются, там прикидываются переменные окружения, чтобы например другую, изолированную базу данных использовать на продакшене. Чувствую, что изобретаю велосипед.
