If your environments are per customer, I would suggest in your specific case to have a repository per customer. (In general it is repository per environment.) This repository would have a standard directory structure for environment variables, ansible variables and inventories, strongly encrypted secrets (account access tokens, private keys, etc.). You would git submodule the code into those repositories. I would probably do it in multiple repositories. One for ansible roles and modules, one for maintenance and deployment scripts, one for each major application running in the environments.
Now you can optionally actually fork the code or otherwise pin the submodule at specific tag for release, making sure that the code managing the customer's environment would not change unless tested and released.
If you are using an artifact repository, make sure the artifacts are properly versioned and those versions are specified in the environment variables properly.
Automation is important because the environment variables should not be updated by humans where possible, but generated by scripts. Make sure that there are nearly no manual updates in the per customer inventory and developers only update the code repositories. If they want to make configuration change, it should be done to one of the generating scripts, which is then run to generate the variables and the diff is committed into the customer repository. It pays to setup continuous integration for this process. Without this at some point there will be too many repositories to maintain.