I want to verify that my services (used to collect data from database and handle it according logic) are not connecting to production database which can cause data loss. my first idea was to mark the service with its configuration file with Enviroment property and verify it against DB's data but our QA enviroment database is replicating its data from production DB so I can't rely on Database data.
A number of options:
- Using firewall, block anything from accessing production database except a few servers that are allowed. This should be done always in production.
- Define production configuration on the production server and don't check it in source control. Source control should maintain only development configuration file with the development connection strings.
- Use different roles in the database for different environments. Say service-dev and service-prod. With service-dev not having access to production.
This is going to depend on what language you're using, but you should have one configuration for debug and one for production.
You can either focus on ensuring the wrong config is never deployed with your project, you can never run the project on the same server as the database is on (assuming you have disabled remote DB connections), or you can make sure that the wrong config cannot connect to your production site.
I would suggest simply having a different password on your production site to the debug site, so if the test application accidentally tries to connect to the production server, it will get an access denied error.
You can usually do this by having a different role. For our setup, we use windows authentication on debug/test servers, but live requires a specific database user with a password, and windows authentication doesn't work. This means there is no possible way anything other than production code can hit the production server/database.