How to deploy a "complex" project?

Question

Heroku

I learned a little in gitlab ci / cd, and deploy through it to heroku. It turns out it's a lot of fun :)

Now I have, at least for me, a very difficult question.

For example, we have a
project - a folder with a project, here are all sorts of docker configs, docker-compose itself, etc.
-> api - here is a folder with an apishka: a lara project, with a separate git configured by ci / cd, everything is pushed to separate stages and production in heroku
-> front - also a separate folder, but with a front written in view, everything is also deployed via ci / cd to heroku
-> go - another separate folder, with my attempts in go, it is also pushed through ci / cd on heroku

In general, so far it's all working and poking
But I'm not satisfied with the fact that if I change something, then I have to push it all separately by gits. Or is it ok? Or is it possible to somehow combine everything into one git project and so that everything is somehow configured there? I wonder how the issue will be resolved if, for example, the api gets pushed, and the front fails at the build stage, or the front is assembled, and the api fails during tests, how to regulate this?

in ci/cd the front is just assembled, in stage and then in prod. And the back is going, being tested, in stage and then in production

Answer 1

I have a similar story. There are 3 projects. One is the face on VUE is a separate folder. But the docker is not there, I just build everything and upload it to a folder on AWS S3 from there everything works like a static site.
There is an API in PHP. So the docker image is running locally and I never even update it. Once I set everything up and everything, I only edit the PHP files. And if you need to push, then I wrote a command, it makes a new image, uploads it to AWS ECR and kills the current container there, so that it restarts with a new image, which takes from 10 to 30 seconds.
There is a project on GO. This is the work environment for every project created in the application. Same story with him. It works locally with the watcher, I just edit the files if I need to push the same thing.
Well, yes, I do everything separately. Although I think it will not be difficult to write a small bash script that will do everything with one command. After all, everything is done by commands in the chest of drawers, so just put them one after the other and that's it.
This is not an answer, just sharing experience. Maybe there really are more elegant solutions for this issue, I will follow the topic.
Edition
I think the whole issue here is in synchronization. For example, he released a new version of the API, but the site still cannot work with it, or vice versa, and everything needs to be done at the same time. I think here the best solution would be the following.
We introduce a pause into the application. For example, you set a flag that an update is in progress. Everyone who uses the application receives a warning window that they must wait while the update is in progress and cannot do anything. At this time, you quietly update all the images, and when everything is ready, remove the flag.
And it's even better to write a bash script that will do all this, and put this work in the plan. For example, everything is ready for delivery to production. You set the schedule for 12.00 at night of this day, and at 12.00 the update will happen by itself. The advance will put a flag, warn users, maybe send a letter in 2-3 hours, depending on the criticality of the islands of the application.

Answer 2

1. You can set up an automatic build of all components if there was only one push.
2. You can set up deployment as a separate job and run it if all components are assembled.
2. You can go to semver and deploy compatible versions, but yes, you need to follow the inventory of versions
3. Building is one thing, deploying is another. Several environments are automatically deployed to some test environment, after which a snapshot of the versions is taken. This snapshot is already deployed to the next environments, in which all versions of the components are compatible and work
4. in one git.
Well, that is, there are a lot of options, you need to look at the general SDLC