Creating deploying scheme for wzzzz

[CHeMeS]

Hi!
I started working on deplyoing scheme. Purpose of this scheme is describing ci/cd flow of the project.
I created a draft scheme so we can start discussing it.

Link to draft scheme: https://app.diagrams.net/#G1FDIw6v1pYjOb9y2NSi3I_UcIfg3bn_qu

[Konstantin Kl.]

@chemeshuggah

1. stage db and redis db needed
2. one pull request (is a monorepo) can provoke multiple deployment of multiple services.

f.e. i change 2 services - bot and api in one pull request. This scheme starts two processes - tests and deployment of two services. Is that right - stop all deployment if tests in one service is fail... or success tested service can be deployed not regardles of tests another service? What happening if i change only one service? Another must deploy to?

This needed of more clear schema - how pipeline manages deploy and when start deployment of different services

3. When test fail? When i merge to main? If i merge to main and test fail - does it mean we have broken code in main branch as result?

I think more better are: merge to transitional branch, run a tests, then, if tests success, merge to main and send packages to deploy

4. How code package get from stage to prod?

[CHeMeS]

@KonstantinKlepikov

1. Done.
2. I googled it a little bit and yes, you can make a "project layout" and then trigger only one service pipeline if you commit changing only this service. But it will cost you time, because most of the settings must be done in a repository and affect workflow scripts for github action as well. So the real question here: do you want setting up "project layout" or not? More info here: https://blog.logrocket.com/creating-separate-monorepo-ci-cd-pipelines-github-actions
3. I have a counter question: will there be tests on dev, before pushing to github repo? Or tests start after deploying on github action?
4. Good question, i already asked you that before :) Need more information from you, what you want to do after you ok with stage? And i googled it a little bit and didn't find a clear answer on what happens when your services go to the stage. My guess you setup access for github repo on render as well but it will update after Render github action script: https://community.render.com/t/github-actions-and-pipelines/4640/3

[Konstantin Kl.]

@chemeshuggah

i know what is it "project layout". The question is - how display this in pipeline on scheme? I need complete scheme to build cicd, without any conjectures.

will there be tests on dev, before pushing to github repo? Or tests starts after deploying on github action?

we have only one place for deploy stack - render. With github action we can build code, test code, make delivery of code and send some directives to some external machines, o.c to deployment stage

we not tests any code "on dev". We test in action, triggered by some other action... for example, action "test stack" can trigger if i make pull request from one branche to another - and stack will be tested by github virtual machine

About "you setup access for github repo on render as well but it will update after Render github action script" - where it is on scheme"? How do you suggest I make a "magic button"?

[CHeMeS]

Great! To properly display it on scheme i must ask more questions. For example, you described "test stack" as example of trigger. Can you describe what triggers do you want and what they are supposed to do? Do you want to have a transitional branch?

I think this scheme must not contain links for repository because it's about ci/cd pipeline and source code often in one location. It will over complicated scheme with just more arrows. Instead of this i suggest add info on scheme that github repository is a source for github action/render. But there is one tricky question arise if we got new push just after another (before github action will test new code). In theory is not a problem, stage must be update twice.

About stage and prod. Right now it's "magic" because there are no ideas about it. I googled it and find solutions but it's need more research (using blueprints and different teams on render): https://community.render.com/t/best-practices-for-staging-prod-environments-like-a-pipeline-using-blueprints/4007/2