Azure Service Bus Queue Avoid Message being read across enviroment

Question

Issue description : My development environment Service bus message are populated to my UAT or production queue and message are been processed in those environment..

To summarize my system: We have a campaign management system where emails are sent to users..

We have a worker role which reads input data and populates the Message in service bus queue.

Their is another worker role which reads this message, process and send email to user..

My issue is when we debug, some developer are not checking for correct message queue setting and are populating the message in UAT environment queue. This result in sending email to real user..

So I am looking for a way or strategy, where we have some validation which deducts these unwanted message and not process it.

I am sure we should have process in place to check these config setting but would like to automate these validation..

Answer 1

In the question comments GauravMantri made the statement that you should have different service bus accounts for each environment, which it sounds like you do, but the problem is that the credentials (or SAS tokens) for all those accounts are in the config files. A developer isn't paying attention to which account is set to be used in the config file, thus you end up populating the prod system from Dev.

In the past I've seen this solved by changing the deployment process so that the config file is modified as part of the deployment process (hopefully automated), which is also something Gaurav suggested. The rollout script would load the config file, find the connection string or specific value that needs to differ and replace it with the string used to actually reach the production/UAT system. The actual credentials are usually stored in a secured location that only the Ops folks have access to (and thus the deployment script service account). This way the file in source control never had the actual production credentials AT ALL. By putting the credentials only into the hands of the Ops folks then it drastically reduces who has access to that info. Of course, this also means the developers shouldn't have remote access to the production servers where they can then just peek at it.

By having it baked into the deployment process you don't have to worry about it. I highly recommend making it automated so that the Ops folks don't have to remember it either. The developer will never "forget" to set the correct values because the only values in source control are to the dev environment (or test maybe).

In really small shops it may makes sense for the developer to actually know the production environment credentials, especially if they are first line support for the system; but I'd still remove them from source control and then the developer that uses them had to make a conscious decision to do so.