And University of Kent we have quite a good system set up by my predecessor, Skylar Kelty.
We use gitlab and every commit goes through the review apps and we get a score card and/or pass fail from each for things like linting, style, coding errors etc. I would like to make more use of the testing capabilities but we are quite busy, so not there just yet in terms of behat testing our own plugins.
We are not deploying from gitlab (we use the https://deployer.org/ to do deployment) but do have a good model of using .gitmodules for all Moodle plugins (each plugin is a separate repository) which makes it easy to both deploy a full Moodle set and also maintain forks of repositories where we either developed it ourselves or needed to modify someone else's plugin.
The development environment runs in Docker, using a combined php & nginx container which mimics our live environment, plus a db container (same) and other tools. We are not running true devops (maybe one day), but the dev environment is very close to live.
Between live and dev are some demo / test servers which the faculty learning technologist and interested parties access and use to try any new developments, new Moodle releases etc.
We have so far resisted having copies of the live database replicated on demo / test servers. There are test "modules" which put Moodle through it's paces but having student info is currently a step too far.
Regarding the config.php, we have a suite of configurations specific to platform (live front end, live back end, demo, dev) which get symlinked into place as part of the deployment.
The Moodle platform is quite robust at the moment, so we haven't needed to do load testing. We have four vms running front end web services, two running cron, scheduled and adhoc tasks, and a dedicated server for uniconv (assessment document processing). Skylar has worked for over 5 years reducing page load time and performance overhead, and the use of redis has played a major part in helping to keep user performance up. He also created a shared file structure so that every Moodle year (each Moodle year is a separate deployment here) can rollover modules from other years and where they normally would duplicate content/files we store them all in the one file service.
Gitlab has certainly played a large role in building towards devops, and it will be interesting to see how your adoption goes forward.