I'm learning how to build the infrastructure provisioning pipelines in Azure DevOps and looking for some step-by-step tutorial to deploy for instance the vnet and a VM in Azure using both methods - ARM templates as well as Terraform
Any help highly appreciated,
Thanks,
Andrey
ARM template:
Firstly, you need have one template which it can be deployed to azure to create VM and Vnet. Just refer to this sample: azure-quickstart-templates. Then do some changes into the JSON scripts based on your actual demands.
The CI/CD structure in azure devops also very easy.
1) Build:
Since the template scripts do not need any build process, it only need 2 tasks to pack and publish the repos as artifact. So that release can use them.
- task: CopyFiles#2
displayName: 'Copy Files to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: '$(Build.SourcesDirectory)'
TargetFolder: '$(build.artifactstagingdirectory)'
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
2) Release:
In release pipeline, it just need one task: Azure Resource Group Deployment task.
This blog has detailed description on how to configure the task.
Terraform:
Same with ARM, here you also need one terraform scripts.
1) Build
For tefrraform, the build configuration same with ARM. Just need publish artifacts.
2) Relesase
See this detailed blog: Terraform deployment with Azure DevOps
Related
I have an Azure DevOps pipeline step failing running the OWASP dependency check. I want to find what dependencies need to be updated.
The logs that are written during the dependency check pipeline step say:
[INFO] Writing report to: e:\vsts\a\7567\TestResults\dependency-check\dependency-check-report.html
I assume this dependency-check-report.html is where it will tell me what dependencies need to be updated. But I do not understand where this e:\vsts\a\7567\TestResults\ location is, as this step is being run in DevOps. Is this somewhere in DevOps? I cannot seem to find it anywhere. "Download logs" on the pipeline page doesn't seem to have it either.
where this e:\vsts\a\7567\TestResults\ location is
When you run the pipeline in Azure DevOps, this path represents the local path of the machine where the agent locates.
In your case, the agent is self-hosted agent. You go to the local machine where the agent locates and find the dependency-check-report.html in e:\vsts\a\7567\TestResults\dependency-check.
On the other hand, you can use the Publish Pipeline Artifacts task to upload the target file to Pipeline artifacts.
For example:
steps:
- task: dependency-check-build-task#6
displayName: 'Dependency Check'
inputs:
projectName: test
scanPath: test
continueOnError: true
- task: PublishPipelineArtifact#1
displayName: 'Publish Pipeline Artifact'
inputs:
targetPath: '$(Common.TestResultsDirectory)'
artifact: drop
Note: You need to set the continueOnError: true in OWASP dependency check task.
In this case, the dependency-check-report.html on agent machine will be uploaded to Azure Artifacts.
For example:
I'm using and on-premise installation of Azure DevOps Server 2020 Update 1.2. I'm trying to configure the build pipeline to obtain the diff coverage indicators in the files tab of pull requests as shown in https://learn.microsoft.com/en-us/azure/devops/pipelines/test/codecoverage-for-pullrequests?view=azure-devops
I created two .Net Core projects one in Azure Devops Cloud and one in our on-premise server. The indicators appear in the cloud project but not on the on-premise hosted one. The only difference between both is that the on-premise linux build agent is based on RedHat instead of Ubuntu.
Are there requirements on the server or software that need to be installed on the server or the agent to get this coverage indicators working?
These are the relevant steps of my yaml pipeline:
- task: DotNetCoreCLI#2
displayName: 'dotnet restore task'
inputs:
command: 'restore'
feedsToUse: 'config'
nugetConfigPath: '$(Build.SourcesDirectory)/NuGet.config'
- task: DotNetCoreCLI#2
displayName: 'dotnet build $(buildConfiguration)'
inputs:
command: 'build'
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: 'dotnet test $(buildConfiguration) v2'
inputs:
command: 'test'
projects: '**/*Test/*.csproj'
arguments: '--configuration $(buildConfiguration) --collect:"XPlat Code Coverage" --collect:"Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=json,cobertura,lcov,teamcity,opencover,coverlet -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.SplitCoverage="True"'
publishTestResults: true
This feature is currently not available for Azure DevOps Server 2020 Update 1.2.
Currently, we can only see the feature in the RTW Release Notes for Azure DevOps Server 2020 RC1.
For this, you may access this URL: https://aka.ms/AzDevOpsIdeas to submit any comments and proposals for future releases and implementations.
Is there any possibility to get the URL of a published artifact in the yml pipeline, so it can be used in further pipeline tasks/steps?
Sadly, the Microsoft Docs on the two tasks don't give any hints if the published path value is available in any way.
- task: PublishBuildArtifacts#1
inputs:
pathToPublish: report.html
artifactName: HtmlReport
It depends on where you're using the artifacts - Deployment jobs will typically automatically download the artifacts into the $(Pipeline.Workspace) folder with the same name as you declare in the build task.
So in your case it would be located at $(Pipeline.Workspace)\HtmlReport
You can also use the Download Build Artifacts task to download a specific artifact:
- task: DownloadBuildArtifacts#0
inputs:
buildType: 'current'
downloadType: 'single'
artifactName: 'HtmlReport`
This is useful if you have multiple published artifacts and you only want to download one of them in a later stage. There are other options if you wish to download an artifact from a different pipeline.
Note that the Publish Build Artifacts task is now deprecated and you are recommended to use the newer Publish Pipeline Artifacts and matching Download Pipeline Artifacts tasks:
We recommend upgrading from build artifacts (PublishBuildArtifacts#1 and DownloadBuildArtifacts#0) to pipeline artifacts (PublishPipelineArtifact#1 and DownloadPipelineArtifact#2) for faster performance.
I’m using Gatling on my local machine. Now I need to move tests to our Azure DevOps server on prem version.
Anyone who has done this? I’ve not found a tutorial for this.
Since you are using the Azure Devops Server, you need to create a Self-hosted agent.
Then you can use your local script to run the gatling test.
Here is my maven gatling test example:
Yaml sample:
steps:
- task: Maven#3
displayName: 'Maven pom.xml'
- powershell: 'mvn gatling:test'
workingDirectory: '$(build.sourcesdirectory)'
displayName: 'PowerShell Script'
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: '$(Build.sourcesdirectory)'
We're trying to release an Angular 7 / .NET Core application into Azure using the DevOps release pipelines. I have my build setup to create the .NET and Angular builds as separate artifacts which you can see in the screen shots below (under the Package or Folder box).
From what I've read it seems that you need to create two separate release tasks to deploy the builds to the web app. However the second build seems to be overriding the first which is causing the API not to start.
Does anyone know of a way to ensure the deployments in a given stage simply appends the changes rather than replacing them? Or is there something else I am missing here?
My recommendation would be to implement the following pattern for your pipeline:
'ng build --prod' the angular app in it's own job, and add the artifacts to your pipeline
'dotnet publish' the dotnet core api in it's own job, running in parallel with the angular job, and add the artifacts to your pipeline
Append the Angular and Dotnet Core artifacts together into a new artifact. This serves as your final package to deploy
Deploy the final package
You're missing step 3, so you'd want something like the following logic defined in YAML, where you create a new zip that represents your actual deployed bits in your pipeline. Then release that artifact, since it is the representation of what you have running on your instances.
- job: CreateReleaseArtifact
displayName: 'Package for shared-hosting of angular app and web api'
pool:
vmImage: windows-2019
dependsOn:
- BuildNetcore
- BuildAngularApp
condition: succeeded()
steps:
- checkout: none
- download: current
- task: CopyFiles#2
displayName: 'Copy WebApi Files'
inputs:
SourceFolder: $(Pipeline.Workspace)/api
Contents: '**/*'
TargetFolder: $(Pipeline.Workspace)/package
includeRootFolder: false
- task: CopyFiles#2
displayName: 'Copy Angular Files'
inputs:
SourceFolder: $(Pipeline.Workspace)/webapp
Contents: 'wwwroot/**'
TargetFolder: $(Pipeline.Workspace)/package
includeRootFolder: true
OverWrite: true
- publish: $(Pipeline.Workspace)/package
artifact: package
Does anyone know of a way to ensure the deployments in a given stage simply appends the changes rather than replacing them?
Based on my experience, in your case, after deploy the API or Angular 7, then I you could use the Kudu zip API to upload another one to the Azure WebApp.
You could use the Powershell task to do that. For more inforamtion about powershell demo code, you could refer to this link.
If creating another WebApp is acceptable, you could add a new WebApp and use the same service plan (no extral cost). Then you could deploy them separately.