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.
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 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
Im working on a simple deployment pipeline with azure devops. I created a deployment pipeline running on a self hosted ubuntu deployment group.
The pipeline looks like this:
Download artifacts from CI pipeline (created with dotnet publish)
Stop running deployment
Unzip the ASP.NET Core Web API to the deployment directory
Run new deployment with dotnet MyApp.dll
The first two steps work as expected. However, when the dotnet My App.dll command is run, the process runs for 10 seconds with following "error" message being printed at the end:
The STDIO streams did not close within 10 seconds of the exit event from process '/usr/bin/bash'. This may indicate a child process inherited the STDIO streams and has not yet exited.
The deployment task is successful despite the message and the app not running. I tried to work around this feature by using nohup & and relocating the command output. After some research I found that all processes started by a pipeline agent are stopped after the agent's work is done - meaning this behaviour is intended and my understanding of azure deployments/agents is wrong.
How do I deploy and run my app in an automated way on my own ubuntu machine using azure devops pipelines?
How do I deploy and run my app in an automated way on my own ubuntu machine using azure devops pipelines?
You are already on the right way.
All the process launched in the pipeline will be finished/clean up in “Finalize Job” step when the pipeline is over.
If you don't want the process to be closed, please try set variable Process.clean= false to stops the "finalize job" step from killing all processes.
But when you create a new pipeline next time, you need to close the app before starting it.
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.
Up until yesterday morning I was able to deploy data factory v2 changes in my release pipeline. Then last night during deployment I received an error that the connection was forced closed. Now when I try to deploy to the production environment, I get this error: "Unable to edit or replace deployment 'ArmTemplate_18': previous deployment from '12/10/2019 10:19:27 PM' is still active (expiration time is '12/17/2019 10:19:23 PM')". Am I supposed to wait a week for this error to clear itself?
This message indicates that there’s another deployment going on, with the same name, in the same ARM Resource Group. In order to perform your new deployment, you’ll need to either:
Wait for the existing deployment to complete
Stop the in-progress / active deployment
You can stop an active deployment by using the Stop-AzureRmResourceGroupDeployment PowerShell command or the azure group deployment stop command in the xPlat CLI tool. Please refer to this case.
Or you can open target Resource Group on the azure portal, go to Deployment tab, find not completed deployments, cancel it, start new deploy. You can refer to this issue for details.
In addition, there is a recently event of availability degradation of Azure DevOps .This could also have an impact. Now the engineers have mitigated this event.