Sometimes your project forces you to do something you rather wouldn’t: debug in staging or production. Although you should definitely try to avoid these situations, sometimes sh*t just happens and that’s fine. If your project is running on Service Fabric, Azure offers you the option to attach a debugger right from within Visual Studio. This is a very powerful option which creates a connection between VS and your service fabric nodes in order to communicate with the remote debugger. Read More
ARM templates are a good way of deploying your infrastructure to Azure as if it were code (it sort of is, actually). Basically you provide a JSON file along with a parameter file and Azure starts creating stuff for you. For more information on how this works (as that’s pretty well documented), check out this link.
One of the options you have when using these templates, is using the outputs section. The outputs section basically tells the deployment task to output some information, which you can then use for whatever purpose you need it. Simple example: suppose you’re deploying an application that relies on a service bus. You’ll need to deploy the bus first, and the application will require a connectionstring to figure out where the bus lives. Using outputs, you can do the following:
- Deploy the service bus, defining an output variable for the connectionstring
- Deploy the application, replacing a token in the configuration file with the actual connectionstring
When you have a pipeline set-up in VSTS (or any other deployment tool), this is dead simple. The cool thing: you don’t have to worry about runtime configuration any more, as your pipeline will ensure everything is set-up in the right way. Nice, right?
Here’s an example of an outputs section:
"value": "[listkeys(variables('authRuleResourceId'), variables('sbVersion')).primaryConnectionString]"
Working with these output, I was trying to figure out which outputs I could actually use. Some articles give examples of which you can copy stuff, but not all of them do so. In the above example, .primaryConnectionString is apparently a property you can use. So how do you know which properties there are!?
The answer is one in the “duh…” category, but it took me some time to figure this out nonetheless. Basically, the resource you are creating determines the properties you can use. Every resource type has a corresponding Get-AzureRm<ResourceType> Powershell cmdlet (or CLI, etc.). To find the type, simply check your template for the “type”: “Microsoft.ServiceBus/namespaces” section. In this case it’s a servicebus namespace, so the corresponding cmdlet would be Get-AzureRmServiceBusNamespace. Run that one and you have your list of properties to pick from, including the option to use a property of one of the child objects. Hope it helps!