CODEWITHSUNDEEP
c#azure-functionsazureservicebus
DenverCoder9
DenverCoder9

Reputation: 1179

Azure Functions V2 With Service Bus Trigger in Development Team

We have Azure Functions (V2) that have been created with the Service Bus Trigger.

[FunctionName("MyFunctionName")]
public static async Task Run(
    [ServiceBusTrigger("%MyQueueName%", Connection = "ServiceBusConnectionString")]
    byte[] messageBytes,
    TraceWriter log)
{
    // code to handle message
}

The queue name is defined in the local.settings.json file:

{
    "Values": {
        ...
        "MyQueueName": "local-name-of-my-queue-in-azure",
        ...
    }
}

This works quite well as when deployed we can set the environment variables to be dev-queue-name, live-queue-name etc for the various deployed environments that we have.

However, when more than one developer is connected locally, given that the local.settings.json file is in source control and needs to be to properly maintain the environment variables, then the local function app runners will all connect to the same queue, and it is random as to which developer's application will pick up and process the messages.

What we need is for each developer to have their own queue, but we do not want to have to remove the JSON config file from source control so that we can maintain a different file (as it contains other pieces of information that need updating).

How can we get each developer / computer running our application to have a unique queue name (but known so that we can create the service bus queues in the cloud)?

Upvotes: 2

Views: 1828

Answers (1)

Mikhail Shilkov
Mikhail Shilkov

Reputation: 35144

You can override the setting value via Environment variables. Settings specified as a system environment variable take precedence over values in the local.settings.json file. Just define an Environment variable called MyQueueName.

Having said that, I think that committing local.settings.json to source control is generally not recommended. I suppose you also store your Service Bus connection string there, which means you store your secrets in source control.

Note that default .gitignore file has it listed out.

If you need it in source control, I would commit a version of local.settings.json with all variables with fake values, and then make each developer setup the proper values locally and then ignore the changes on commit (set assume-unchanged).

Upvotes: 2

Related Questions