Goal: implement CI\CD and update (by commit or pull request) of environment (dev1…dev3, qa, staging) from appropriate branch (feature, hotfix, dev or even prod). Application from any branch could be delivered to required env.
Problem: need to decide where to store configuration (for example connection string or some settings or docker-compose files):
- in the repository of the code (Configuration as code, for sure) or
- create a new configuration repository for each microservice, or
- create a single configuration repository for all microservices (per environment).
I can’t find enough information about this. In most cases they talk about single application and single repository. Maybe there are some mixes from GitOps and DevOps which doesn't allow to have a complete picture of what to do. Could you please clarify this part and maybe provide the right strategy?
Also I found some levels of separation:
- infrastructure + configuration + app code (all in the same repo)
- (infrastructure + configuration) code from app code (2 repos for each app)
- infrastructure code from configuration code (2 repos for each app + infra repo, which looks like different branch per environment)
Not clear what belongs to infrastructure and what to configuration code. For example: logging level, docker-compose files, env. variables with connection string in appsettings.json.
Infrastructure description: 10+ micro services with .net core. Each has own repository for code. The configuration files are stored now in the same repository with code as appsettings.json (has overriders like appsettings.qa.json) or as env. variables (pass it to docker-compose), or docker-compose or Jenkins files. So, as for me configuration is split from code.
Containers: we use docker to create an image of the container and nexus as image repository. We pass configuration from config yaml files during compose phase. There is an information about GitOps which says to store configuration of each service in a separate own repository. But this sounds strange and not consistent, because now my code is close to the settings, changes in one place and this looks correct not overcomplicated.
For example, there is such a scenario:
I add RebbitMQ support for half of my micro services in a new Feature Branch of Service 1 Repository. If I store configuration in the same repo with micro service’s code, then I’ll have no problems to set all settings during coding and pass CI\CD with new integration (with RebbitMQ). After that I can deploy service with connection to RebbitMQ to Dev Environment, check how it works and merge if all is ok to prod.
But if I have a separate Service 1 Config. Repositories for each service where branch = environment (dev1, qa), then it’s not clear which env\branch should I update, while feature was not release, but the dev1 environment will be already updated with RebbitMQ settings. But this feature may be never release and removed, while changes in dev1 branch already exist.
Or should I follow different approach and create branches in Configuration Repository equal to branches in Application repository (branch per feature)? In this case I will have to create a feature branch for each repo (extra work) and keep in mind, not to forget to commit configuration for all of them later. It looks like a huge overcomplicated thing, doesn’t it?
Also, it’s not clear what to do with appsettings.json files which are part of application (micro service), could be overridden by ENV variables (appsettings.qa.json will be used if env=QA) and how should they appear in the Configuration Repository ?
Another scenario is also not clear:
How to deploy “Service 1 v.2.0” and “Service 2 v.1.0.” to the same environment DEV1., while “Service 1 v.1.0” and “Service 2 v.1.0.” to QA env. Where to store configuration, connection strings in this case?
Here is an example of repository which stores configuration as code in the same repository with microservice:
Here is an example of repository which stores configuration as code in a split configuration repositories (one-to-one for each micro service):
