How to build CI/CD for one developer and several projects?

Question

Node.js

Task:
Build a convenient and stable CI / CD system for several projects with a single code base in the conditions of one developer with the possibility of expanding to a small team

Given:
-One developer + laptop on a poppy.
-Several NodeJS projects that want to share a single codebase.
-Gtilab and only recently implemented habit to at least commit and use branches.
-CentOS on a server + a separate mongo instance + aws s3 compatible storage for all user downloads
-Nginx is now used as a reverse proxy and NodeJS applications are spinning on different ports using pm2
-Building takes place on a poppy and is unloaded simply via rsync

Problems:
- Deploy .It is already clear that rsync needs to be moved away. One of the packages in the dependencies (needed only to compress avatars) nevertheless turned out to be compiled with the specifics of Linux or poppy. Of course, there is an option to hang it as a separate microservice, maybe even somewhere on external lambdas, but this will turn out to be a crutch. And where to go from rsync?
> Can the autobuilder just be configured with gitlab hooks? But then you will have to build it on the production server itself, which will spend resources on it, which looks clumsy.
> Can docker-compose somehow solve the issue? And if you screw Docker-compose, then how to build the deployment further? It is necessary /somehow/probably to set up GitLab CI/CD. And where should the auto-testing take place? On idea it is enough that before kommit it was? Or is it still on the side of Gitlab?
> Is it worth using Kubernetes right away if one instance is enough for now? It will probably be a PPC to configure it yourself, then take managed, but pay for it one and a half to two times more than for the same resources without Kubernetes. Is it worth it? Will it give a simple dev experience?
> Or maybe nafig spit on everything and build everything on serverless? Take Vercel. So what if there are the nearest servers in Europe and the ping will be about 60ms instead of 15-20ms. True, then the base would be moved there closer, because in a number of moments there will be a series of successive requests, which will multiply the time. Or it will get very confused with caching ... Or can Frontend just take it there, and leave a single back next to the base? Will it make life much easier?

- Type forwarding between back and frontA working solution is to make a single backend (NestJS) and several separate frontends (NextJS). And use GraphQL's static type generation to link backends and frontends. I don’t know if this will be enough, or is it still worth doing DTOs, and if they are, it’s not clear how to fumble between the front and back.

- How to build staging? Although I write tests, I don’t always update them and don’t run them before each deployment. Now confusion with all these ports. Different branches are collected in different ports, environment variables are pretended there, so that, for example, another, isolated database can be used in production. I feel like I'm reinventing the wheel.

Answer 1

Build & deploy - Gitlab CI/CD https://docs.gitlab.com/ee/ci/ .

How to build staging?

I would do it on a separate server with the same ports

Answer 2

Code -- in self-hosted Gitea https://gitea.io/en-us/
CI/CD -- in self-hosted Drone CI https://www.drone.io/ , he can do dockers and everything, what you want.
For everything, a small VPS with a couple of cores and 2GB of memory is enough, on which the gitlab will not start.

Answer 3

Specifically, I have a cube cluster from DO and a paid github with their ci / cd.
Once I set up ci / cd and everything is automatically packed into the docker and goes to different cube namespaces.
Climbing into your gitlab, given that there is only one developer, I don’t advise maintaining your infrastructure for a long time, which means it’s expensive. You can get away with this if you have a large team. If you are talking about cloud gitlab, then use their ci.