I have a resource group containing multiple function apps as follows:
These functions app only have one production slot:
I would like to add a staging on all these function apps so that during deployment (via Azure Dev Ops), it gets deployed to staging slot first. How do I do that via PowerShell commands/ARM templates? Also, what updates need to be done in order to test in staging environment before deploying to production slot?
I'm not sure about the Azure DevOps! Normally, I would do these changes when publishing to and testing in the Staging Slot in Azure Function App or App Service.
Please check if the below workaround helps to:
In the Portal of Azure Function App - Deployment Slots, Add a Slot:
My Function App is in consumption plan, so it has limit of 2 Deployment Slots. Refer Function App Limits for more information.
From Visual Studio, I can choose the deployment slot where I need to publish the Function App like below:
Also, what updates need to be done in order to test in staging environment before deploying to production slot?
Suppose when publishing and testing the application in staging slot, I need to see all the request-response logs, traces and metrics. Then I would select the few configurations setting as deployment slot setting to capture staging logs like:
Check the App Insights Instrumentation Key deployment slot setting to get the Application Insight Logs/Traces from the staging slot:
Note: Azure Functions deployment Slots
Related
Let's say I have a YAML pipeline, releasing to dev and prod, and I want to set an approval before releasing to production.
Currently, this can be done via Environments approvals (MS Docs - Define approvals and checks).
However, this seems to work only for virtual machines.
How can I set an approval when releasing to Azure PaaS components, e.g. Azure function or Azure App Service?
To achieve this, go to service connection that is used to connect to cloud env, and set the approval there.
Project settings -> service connections -> select your connection (prod) -> click the three dots -> approvals and checks.
In your pipeline you need to define a deployment job, specifying an Environment which is configured to require an Approval.
I am doing CI/CD on Azure Data Factory.
I do have a DEV instance and PROD instance of Azure Data Factory.
The deployment process is going smooth except one problem with the triggers.
I do have around 20 triggers in which 15 are in running state and 5 are stopped for a while in PROD.
Since DEV ADF is a development instance and i do not want to run any of the triggers in scheduled manner in development instance status of all triggers are set to stopped.
Currently the trigger status changes from DEV to PROD deployment is by replacing the string '"runtimeState": "Stopped"', '"runtimeState": "Started"' in the ARM template json file.
But this will start all of the triggers in the production after deployment along with the 5 triggers which are stopped for a while.
Is there any way to un touch the trigger status at the time of deployment in PROD and only add newly created trigger into PROD without touching the existing triggers in PROD?
You can add an Azure PowerShell Task to do this activity.
You can write a PowerShell script to Start/Stop trigger and place it in relevant pipeline.
In below case, I have stopped all triggers before deployment, you can add Pre or Post deployment step via PowerShell to achieve this.
I am trying to create a setup where I deploy a "Webapp for containers" but I want to build in some checks via Azure Monitor. My idea is to deploy the webapp and then have a gate that checks an azure monitor alert set with availability. When the availability check fails then it should rollback.
The documentation states "When the release pipeline detects an Application Insights alert, the pipeline can gate or roll back the deployment until the alert is resolved", but I don't know how to configure this in azure devops.
I have an AppService Plan and a web app running. I also created an Application Insights instance and I enabled continuous monitoring through the "Azure App Service manage" task.
The alert I created is:
az monitor metrics alert create -n 'Availability' -g ${RG_NAME} --scopes "${APP_INSIGHTS_PROD}" \
--condition 'avg availabilityResults/availabilityPercentage < 90' \
--description "created from Azure DevOps"
As Post Deployment-Condition I enabled the Gates and I configured it to check for the Availability alert, which works. When I adjust something to make the app fail on purpose the Gate works and fails the Stage eventually.
I also enabled the auto-redeploy to deploy the last successful deployment but that does not do anything because the actual deployment task was successfully finished.. just the gate failing and failing the stage.
I build the Release via the UI, to make it work I had to create the pipeline via yaml. With deployment jobs I could use environments and in the Azure DevOps UI you can configure the environment to add a check. Query Azure Monitor Alerts is one of the available checks to add for an environment.
The check is done at the beginning of a job so I created a separate deployment job that refers to the environment with the Query Azure Monitor Alert check.
After that I created another job that has a dependson and condition which will only run if the query alert job failed. And that job will swap slots.
My project is Windows Service application which could be installed in several roles (the difference is in service name, exe path and some setting in app.config). Each role could be scaled horizontally by instances count. And all these {roles x replica counts} should be deployed over a set of servers in specific proportions for effective performance and utilization.
As an example:
ServerA
ServiceAlfa.1
ServiceAlfa.2
ServiceBravo
ServiceDelta
ServerB
ServiceBravo
ServiceCharlie
ServiceDelta.1
ServiceDelta.2
ServiceDelta.3
How can I achieve this with Azure DevOps (Dev17.M153.5) instruments?
I know brand new yaml pipeline introduces some conception of Environments and VM. It's just not available in latest stable version yet. But it's like a replacement for Deployment Groups early used for deployment to multiple machines, which I can use. I have already installed deployment agents and registered it. But I still cannot figure it out how better configure my complex mapping of instances to servers in release pipeline.
I can create a one job stage per role and link them with corresponding variable groups like
StageAlfa
ServerA:2
StageBravo
ServerA:1
ServerB:1
StageCharlie
ServerB:1
StageDelta
ServerA:1
ServerB:3
So I should check and compare the server name in my script
Or I can do the opposite: create a stage per machine and link it with variable group describing count of specific role replicas on current server. So in every stage I could select specific machine from deployment group by tag.
Looks like the second approach is simpler but they both are felt so awkward!
P.S. Windows Services on Machines not a containers in Kubernetes due to specific Windows software dependencies.
Your approaches are correct. You may consider migrating to Azure DevOps Service or upgrade to Azure DevOps Server 2020, which supports Envorinments and VM:
https://learn.microsoft.com/en-us/azure/devops/server/release-notes/azuredevops2020?view=azure-devops#continuous-deployment-in-yaml
Lets say I'm deploying an Azure VM by scripting which requires multiple resources interdependent on one another.
Lets say a NIC fails,
Does the deployment script still go through to the deployment of the VM? So that I have a VM with no NIC
Does it fail rolling back the entire script?
No ARM templates are not executed within a transaction.
It's possible that you have deployed resources without deploying the whole ARM template. In your case it's not possible to have a VM without a NIC (But you test the deployment of the ARM template and make it work at the end.)
It does not roll back.
I think now they have added "--rollback-on-error" flag to rollback on last successful deployment if the deployment fails. Also you can specify the name of the deployment to which you need to roll back refer this: https://learn.microsoft.com/en-us/cli/azure/group/deployment?view=azure-cli-latest#commands.