Q21: Explain the structure of simple Azure CI pipeline?
Q22: In Azure DevOps when to use Azure Container Registry (ACR) and when to use Azure Artifacts?
Q23: Give me the real-life example of when you might need to use Azure Artifacts to share libraries and dependencies?
Q24: Throw some light on how to use the Azure Devops Unit test pipeline in your project.
Q25: How many pipelines you can run parallelly in Azure DevOps?
========================================================================================
Q21: Explain the structure of simple Azure CI pipeline?
Answer:
When you choose the “Build and push an image to Azure Container Registry” template in Azure Pipelines, it sets up a YAML pipeline that automates the process of building a Docker image from your source code and pushing it to an Azure Container Registry (ACR). Here’s a breakdown of the key components of this template:
1. Trigger: Specifies when the pipeline should run. Below it is set to trigger on chances made to main branch
trigger:
- main
2. Pool: Defines the agent pool where the pipeline will run. We have our self-hosted pool, VM image here act as a pool.
pool:
vmImage: 'ubuntu-latest'
3. Variables
variables:
# This is an identifier for the service connection to your Azure Container Registry (ACR). It allows the pipeline to authenticate and interact with the ACR.dockerRegistryServiceConnection: 'a16b2ea1-c9e6-4a49-b32e-48aced480532'# This specifies the name of the Docker repository where your image will be stored. In this case, the repository is named votingappimageRepository: 'votingapp'# Url to Azure Container Registry. There is where docker image 'votingapp' will be stored.containerRegistry: "<<ACRName>>.azurecr.io'# Source location of Docker file. Which will used to create image.dockerfilePath: '$(Build.SourcesDirectory)/result/Dockerfile'# Tag is used to identify the build number of image.tag: '$(Build.BuildId)'
3. Stages-->Jobs-->Steps-->Tasks
<< below is from Step directly>>
steps:- task: Docker@2inputs:
# Specifies the service connection to your ACR.
containerRegistry: '$(dockerRegistryServiceConnection)'
# Name of Docker Repository
repository: '$(imageName)'
# Command to Execute. build and Push.
command: 'buildAndPush'
# Path to Dockerfile
Dockerfile: '**/Dockerfile'
tags: |$(Build.BuildId)
========================================================================================
Q22: In Azure DevOps when to use Azure Container Registry (ACR) and when to use Azure Artifacts?
Answer:
In Azure DevOps it's as common practice to use: -
ACR for storing and managing docker images in case of Microservice architecture.
While Azure Artifacts is designed for managing and sharing packages like Nuget, npm, Maven, Python etc. Azure Artifacts are NOT primary designed to store docker images.
ACR Common use case:
>> ACR supports Geo-Replication allows you to replicate container images across globe.
>> It has easy integration with AKS (Azure Kubernetes Service)
Azure Artifacts:
>> use of storing libraries, dependencies, and other packages used in application.
>> Azure Artifacts allows the versioning and thus you can maintain the different version of same library etc.
========================================================================================
Q23: Give me the real-life example of when you might need to use Azure Artifacts to share libraries and dependencies?
Answer:
Consider we have a microservice architecture with MicA, MicB, MicC. All 3 have their own set of dependencies and some of them are shared across multiple other microservices.
Managing dependencies version across all Microservice is crucial to avoid any version conflict.
Dependencies are of two types
1) External decencies coming from public NuGet and
2) Dependencies/ libraries which we are creating, and it will be used in other Microservices. eg MicA produces CommonUtility_Lib_1.0.0, that is used in MicB and MicC
2) Dependencies/ libraries which we are creating, and it will be used in other Microservices. eg MicA produces CommonUtility_Lib_1.0.0, that is used in MicB and MicC
In type 2. During the build process of MicA, we can package our shared library CommonUtility_Lib_1.0.0 as NuGet package and published it to Azure Artifacts.
Other Mic services like MicB, MicC can now consume this shared library version reducing the risk of version conflict.
========================================================================================
Q24: Throw some light on how to use the Azure Devops Unit test pipeline in your project.
Answer:
Azure devops doesnt provide its own testing framework but it has good integration with existing framework like NUnit, XUnit, MSTest etc. There is a key difference in how these test are executed in CICD pipeline and how they are executed in normally with fucntions.
In my case it was dotnet core project and we had NUnit testing framework which has 3 things Assign, Act and Assert.
So the steps at pipeline were as below:
1. Trigger the pipeline (Eg chages in Main branch)
2. use of self hosted Agent like ubuntu server
3. install the .net sdk
4. Retore the nuget packages.
5. Build the .net project.
6. Run NUnit test project and logs the result
7. Publish the test result on DevOPs. So I added a task for this. I selected the "Publish test result" task template from the pipeline itself. You will also find a new tab in pipeline as shown below
========================================================================================
Q25: How many pipelines you can run parallelly in Azure DevOps?
Answer?
It depends on we are using 1. Microsoft Hosted Agents or 2. Self-Hosted Agents
Microsoft Hosted Agents:
1. Free Tier:
A) Public Hosted: 10 Free parallel jobs are possible in every 6 hours.
B) Private Hosted: 1 free parallel job in every 60mins.
2. Paid Tier: 25 Parallel jobs. Public/Private doesnt matter.
Self-Hosted Agents:
No limit to parallel jobs that can be run. but only 1 job can run in 1 agent, if you want to run multiple jobs than multiple agents need to be created.
========================================================================================
No comments:
Post a Comment