Hi,
I’m trying to figure out how I can verify that placeholders (e.g. #{MyVariable}) is replaced in each config file when I deploy to Azure App Services using the new Azure App Service deploy task.
I found this: Verify AppSettings or Variable Replacement - Octopus Deploy – this works great for IIS deploys and probably also using the legacy “Deploy an Azure Web App (Web Deploy)” task as well. However for the new “Deploy an Azure App Service” task that was added recently, there is no support for custom deployment scripts.
So my questions:
- Is there any plans to introduce built-in support for failing the deployment if any variables are missing without having to depend on a script for each deployment task? I think this is a very common scenario?
- Is there any plans to introduce support for custom deployment tasks to the new “Deploy an Azure App Service” task?
- Is there a good workaround currently for checking for placeholders before deployment using the new “Deploy an Azure App Service” task? Or will I need to use the old one?
Thanks!
Hello Hallgeir,
The recommended way to provide configuration to your Azure App Service deployments is through Application Settings. This is supported in the new Azure App Service deployment step under the App Service Configuration heading, which includes both Application Settings and connection strings.
To your specific questions - unfortunately, I don’t think there is any planned work at the moment to incorporate the custom deployment script feature into the new App Service step, and especially within the App Service Configuration block, there’s not a great way to explicitly validate that there are no missing variables or leftovers unreplaced. There’s currently an internal discussion going on around possible ways to improve variable replacement validation, especially to cover use cases like yours where those values are ultimately being set and used on a cloud service to drive deployed app behavior.
There’s no good workaround at the moment for this with the new task, but the previous version (using web Deploy) should continue to support custom deployment scripts if you want to continue using them as described by the blog post. I’ll update more here if anything comes from the other variable validation discussion, sorry it’s not easier to work with the new App Service step!
Hopefully you’ve got enough to get moving forward on your process, please feel free to reach out with any additional questions or needed assistance - always happy to help.
Hi, thanks for the reply.
We have some good reasons to keep using variable transforms, so completely switching to app settings in Azure App Service isn’t an option at this time. We’re using it for a select number of app settings. In any case, this wouldn’t really solve anything related to missing placeholders. If the variable is missing, it would not be resolved in app settings either, or the value would be empty (which may be just as bad).
Regarding my question #1 - if this can be solved, there’s no need (for us) for a pre-deployment script. And I think this would be hugely beneficial not only to app service deployments, but also IIS deployments, not having to muck around with pre-deployment scripts.
The issue with using the old version of the app service deploy (the webdeploy version) is that it doesn’t support adding AppSettings and connection strings though. We’ll have to see if we can work around this somehow.
I agree - there’s not a great one size solution based on the support for Application Settings in the new version of the step without also supporting custom deployment scripts. The one benefit you get from Application Settings is that you can see the expected values to be replaced, rather than them being effectively invisible inside the package, so you can visually validate that you have a 1:1 match between your defined and expected variables.
Unfortunately, I don’t think there’s a great way to validate variable replacements in these steps at this time. I did write up this use case for our internal teams so they could take it as input to ongoing decisions.