GitOps - Config in same repo or seperate repo?

Firstly this is in the context of a mono-repo application that runs inside Kubernetes.

In GitOps my understanding is everything is declarative and written in configuration files such as YAML. This allows a full change history within git. Branches represent environments. For example:

• BRANCH develop Could be a deployed QA or staging environment
• BRANCH feature/foo-bar Could be a deployed feature branch for assessment
• TAG v1.2.0 Could be latest version running in production This makes sense to me, any and all branches can be deployed as a running version of the application.

QUESTION I remember reading ... somewhere ... configuration should live outside of the main repository, inside another "configuration repository". From memory the idea is an application should not know a particular configuration... only how to use a configuration?

Is this true? Should I have an application repo and an application configuration repo? e.g.

• app repo: foo-organisation/bar-application
• config repo: foo-organisation/bar-application-config

Where the branching model of config for different environments lives inside that repository? Why and what are the advantages?

Otherwise should it just live inside a directory of the app repo?

There's no real hard rule other than everything about your environment should be represented in a git repo (e.g. stop storing config in Jenkins env variables Steve!). Where the config lives is more of an implementation detail.

If your app is managed as a mono repo then why not use the same setup for the deployment? It's usually best to fit in with your existing release processes rather than creating something new.

One catch is that a single version of the app will normally need to support multiple deployments and the deployment config can often change after an app has been built and released. So there needs to be a 1 "app" to many "config" relationship. Whether that is implemented with files, directories, branches, or repos. They can all work, as long as they are versioned/released.

Another release consideration is application builds. For small deployment updates you don't want to build and release a complete new application image. It's preferable to just apply the config and reuse the existing artefacts. This is often a driver for the separate deploy/config repo, so concerns are completely separated.

Security can play a part. You may have system information in the deployment config that all developers don't need access to or you don't want to even have the chance of it making it into a container image. This also drives the use of separate repos.

Size of infrastructure is another. If I am managing multiple apps, the generic deployment config will not be stored in a single apps repo.