I'm trying to deploy a single project which is separated in multiple git repos, question bothering me is that: should we create a separate repo for kuberentes configs and deployment files or each repo should contain their own deployment code
first solution puts everything in one place, which makes changes easier and also someone can monitor how our deployments changes, (also I think it might be easier to deploy whole project on different staging servers - we don't need to update every repo to change things like tokens, urls, db passwords, ...)
but seconds solution lets devlopers on each repo easily change how their code is being deployed (each repo knows how to be deployed), also it might be easier to deploy the code (if we use a repo for kubernetes, code repo should somehow notify kubernetes repo that the code has been updated or a new docker image is ready on registry)
In Rancher 2.x, Project(s) provide isolation of resources and also Resource quotas. Whether a single user is assigned to a project or multiple users share the project depend on the use case of the organization.
Let's say if a Dev team requested compute resources (say 16 cores and 64 GB) in a cluster, the admin would carve out this quota for the team. Now how these resources get used depend on the team members. One can launch a single workload using all of the allocated cores/memory or share across multiple workloads.
Also enabling network policy would prevent communication across projects. So QA team and Dev team workloads are isolated.
Another use case is to dedicate a project for one organizational application. For example, web server, jenkins, cms could get their own projects.
Now discussing config storage, it follows the above patterns. As a developer, I would like to not deal with configs other than mine. But as an SRE, I might want to group all the production configs in one repo.