I have a number of C# microservices in different repositories. All of these need OpenShift configuration code, including variables, config maps, services description, secrets, etc. I see following variants of storing deployment configs:
There are number of articles about "monorepo vs polyrepo", yet the deployment part is always missing. What are the guidelines here and advantages/disadvantages to each approach?
I will give you my two cents on this, since I went through a similar problem.
This is not really a good idea since often the secrets, config-maps and so on, are different between environments, so you would have to manage environments in each microservice's repository, which then could bring many other problems, like changing settings by mistake in the wrong environment.
Furthermore, many other problems arise when dealing with shared secrets, because you would have to know that a secret X exists in the cluster.
With this approach you separate the code from the infrastructure, however it is hard to have a high view of the whole application, i.e., if you have 10 microservices you would have ten different 10 repositories and you would have to know that each one of them exist and is needed to run the system.
This approach allows you to view all your dependencies and configuration in one place, i.e., your application as a whole. The only issue here is that you might need different permissions to access different environments, e.g., you might want everyone to be able to change infrastructure configurations in the test environment but only a few authorized people in the production environment.
Finally, the best alternative in my opinion is to have a repository for each environment, e.g., you can have a different repository for production, pre-production, test environments. It brings all the advantages of the previous approach with the addition that now it is much easier to control who can change configurations in each environment.
Furthermore, it also allows you to evolve the configurations in a total independent way, e.g., when you develop new functionality, you only need to change the test environment of your application, without the risk of changing something in production.