7.4

В гит залить не должно быть проблемой... Хотя бы как один цельный проект (а не разные с разными модулями).
Получить composer.json из vendor'ов — проблема. Проще сначала заливать vendor в репозиторий.

Дальше берёшь любой конфиг по аплоаду данных на сервер и аплоадишь. А остальным бить по рукам (и сказать об этом заказчику, когда репу передашь).

Вот тебе самая простая конфигурация для Gitlab CI, которая 99% что подойдёт (build этап с командой composer install можешь убрать, если вдруг не нужно будет).

https://gist.github.com/artemmolotov/d8dc4d1bafec58dbaa45da93b10a1828

Главное, обязательно добавь игнор тех файлов и папок, которые на проде хранят какие-то пользовательские или временные файлы. Иначе ОНИ БУДУТ УДАЛЕНЫ. (ну и лучше сначала на своей или дев машине проверить)

Потом коммит и ручной запуск Pipeline (в меню слева).

спасибо

Когда кто-то приходит со своим проектом и хвастается стэком вида C, Go, Angular, MySql, MongoDb, PostgreSql, RabbitMQ, Redis, возникает 1 закономерный вопрос - почему вам не хватило одной реляционной базы?

Сюда же примеры с Kafka + RabbitMQ + NATS или Redis + Memcached. Широкий техстек это чаще минус авторам проекта, и в большинстве случаев вы и так не встретите проблемы, требующие несколько баз сразу (you're not Google at mini scale так сказать).

Признаюсь, у нас у самих было 2 БД одновременно, но все было во время миграции, хотя в итоге остались на старой БД, просто было нерационально переписывать одно и то же. Но вот не все мигрируют, там более годами)

(пока в коменты не набежали с аргументами "да мы монолит 5 лет распиливаем, с пхп+монго на го+пг" скажу сразу, в начале поста упоминается _новый_ проект, сделанный с нуля, и объяснить зачем так, человек не смог)

Почему-то тут же вспомнился 1 СТО, который делал 1 инстанс БД пер сервис. Что конечно делало компоненты независимыми, но так же (имхо) раздувало поддержку этого чуда. И не чуть-чуть счёт.

Под каждую задачу более подходящий инструмент вс унификация стэка?

а потом целый штат опсов чтобы поддерживать всю инфраструктуру ага

это про внедрение  куба в организацию?)

или половина штата разработчиков пытается сделать чтобы мускуль не тормозил с сотней миллинов записей в табличке аудит логов

Kafka + RabbitMQ + NATS

звучит, как булшит комбо. Мол, нахера
1 кафка заменит натс и кролика
натс и кролик разом, в целом бесполезно, у кролика есть фанауты, хуячь в них нонперсистенс мессаги, профит

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

ну почему натс берут я в целом понимаю

а че с кубом то?

типичная го макака, берёт ибо модно среди макак

натс повыёбываться среди гоферов, кролик - ибо ток с ним знакомы, а кафка - что б повыёбываться перед клиентами, мол, у нас тырпрайз

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

ну тип.. тащить кафку это нужен кластер зукипера и собственно кластер еще кафки. втащить кролик это нужен тоже кластер

а так мускуль и редис фактически в каждом проекте есть, который уже саппортят

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

для этого и придумали EKS и GKE

если у тебя там тыщонка-другая сообщений, то взять редиску, которая почти наверняка есть и профит

вот я ж о чем

та же монга, она примерно нахер нигде не нужна. а саппортить ее это такой пиздец