Q31-Q35

Q26-Q30

Q26: What you understand by DevSecOps?

Q27: Tell me how your current project is managing DevOps. Start from Code Check-in Phase?

Q28: How can you relate Azure Test Plan with Azure Test Pipeline. ?

Q29. Difference between Blue Green and Canary Deployment?

Q30: What are the various deployment strategies we have like Blue Green, Canary etc?

============================================================================================

Q26: What you understand by DevSecOps?

Answer:

As an azure DevSecOps it's our duty to ensure that Security is the shared responsibility of both Dev team and operations team. 

As a DevSecOps team, we must assure that our pipeline has all tests present init. 

eg

Unit test

Performance test

Vulnerability test can be done with Github CodeQL like SQL injection, XSS etc

Code Quality Check

Code Coverage

-- DevSecOps also must considere usage of 

>> Azure KeyVault for storing important information. 

>> Azure policies must be intact while deploying infra changes. 

>> use of selfhosted Agents for running pipeline. 

Pre deployment checks like all the instances/ Nodes where our application is going to host must be up and alive. 

============================================================================================

Q27: Tell me how your current project is managing DevOps. Start from Code Check-in Phase?

Answer:

Considering we scope the requirement as below structure

Epic > Features > User Stories > Tasks/ Sub Tasks/ Bugs

Below will be my branching strategy and its impact on DevOps pipeline. 

1. Master(Main) Branch. 

• Purpose: Production-ready, stable code.
• Deployment Target: Production environment.
• Pipeline:
• Fully automated CI/CD for release to production (manual approval gate before prod).
• Protected branch: only merge via pull requests from Feature branches after successful validation.

2. Feature Branches

• Naming: feature/<feature-name>
• Lifecycle: Exists for the duration of the feature; deleted after merge into master.
• Deployment Target: DEV / QA environments.
• Pipeline:
• Deployments to DEV/QA are triggered when Feature branches are updated (PR merges from User Story branches).
• Useful for end-to-end feature testing or integration testing across multiple stories.
• Why: This gives you an isolated integration layer for a feature, which may involve multiple user stories developed in parallel.

3. User Story Branches

• Naming: story/<story-id>-<short-name> (e.g., story/US1234-add-currency-dropdown)
• Lifecycle: Short-lived. Developer pushes their commits here; once the story is complete, a PR is raised to the Feature branch.
• Pipeline:
• Validation Pipeline runs automatically on PR:
• Build
• Unit tests
• Code quality (SonarCloud)
• Security / vulnerability scanning
• Integration tests
• Code coverage thresholds
• Optional performance smoke tests
• PR cannot be merged if validation fails.
• Why: Keeps the integration layer clean and forces code quality gates before story completion.

============================================================================================

Q28: How can you relate Azure Test Plan with Azure Test Pipeline. ?

Answer:

Azure Test pipeline is nothing but a part of CICD pipeline. The logic of Test Pipeline could part of main pipeline or standalone pipeline.

During pipeline runs, automated tests get executed, and their results can be published back to Azure Test Plans. 

That’s the key connection: the pipeline runs the tests, and the test plans reflect the outcomes.

============================================================================================

============================================================================================

Q30: What are the various deployment strategies we have like Blue Green, Canary etc?

Answer:

Majorly 3

1. Blue Green -  Two identical environments (Blue = current, Green = new). Switch traffic instantly.

2. Canary - Gradual rollout to a small user subset, then expand if stable.

3. A B Testing - Split traffic between two versions to compare performance or UX.

============================================================================================

Interview Q

Q: How Does the Azure CICD Pipeline look in your organization. Explan each Stage, Job, Steps and Taks. 

Q: How have you implemented Azure CICD pipeline in your project?

Q: Tell me about the CICD pipeline your project is having. 

------------------------------------------------------------------------------------------------------------------------------------------

Q21-Q25(CI Pipeline)

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 votingapp

imageRepository: '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@2

  inputs:

                # 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

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

 

#69 Publish Test Results in Azure DevOps Pipeline (youtube.com)

========================================================================================

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. 

========================================================================================

Q1-Q5

Q1: What is Azure DevOps?

Q2: What are the stages of SDLC?

Q3: What is the difference between Release and Deploy stages in SDLC?

Q4: What are the key components of Azure DevOps?

Q5: Explain the structure of Dockerfile? Give dotnet 8 dockerfile example.

--------------------------------------------------------------------------------------------------------------------------------------

Q1: What is Azure DevOps?

Answer:

Azure DevOps is a comprehensive set of development tools and services provided by Microsoft to support the entire software development lifecycle. It integrates various aspects of DevOps, enabling teams to plan, develop, test, deliver, and monitor applications efficiently.

--------------------------------------------------------------------------------------------------------------------------------------

Q2: What are the stages of SDLC?

Answer:

SDLC - Software Development Life Cycle composed of following stages in DevOps

1. Planning: This stage involves defining the project scope, requirements, and objectives. Tools like Azure Boards help in tracking work items, managing backlogs, and planning sprints.

2. Development. During this phase, developers write code and implement features. Azure Repos provides version control to manage code changes and collaboration.

3. Build. The build stage involves compiling the code and creating build artifacts. Azure Build Pipelines automates the build process, ensuring that the code is compiled and tested continuously.

4. Testing Automated and manual testing are conducted to ensure the quality of the software. Azure Test Plans offers tools for managing test cases, executing tests, and tracking defects.

5. Release This stage involves deploying the software to various environments. Azure Release Pipelines supports continuous delivery, automating the deployment process to different stages like development, staging, and production.

6. Deploy The software is deployed to the production environment. Azure Pipelines can handle the deployment, ensuring that the software is released smoothly and efficiently.

7. Operate After deployment, the software is monitored for performance and issues. Azure Monitor and Azure Application Insights provide tools for monitoring and logging to ensure the application runs smoothly.

8. Feedback Gathering feedback from users and stakeholders is crucial for continuous improvement. Azure Boards can be used to track feedback and incorporate it into future development cycles

--------------------------------------------------------------------------------------------------------------------------------------

Q3: What is the difference between Release and Deploy stages in SDLC?

Answer:

Release and Deployment are often confused as synonyms to each other but they are different states in SDLC. 

Release Stage:

Ensuring Software is ready for deployment. This stage includes UAT (User Acceptance testing), final documentation, packaging, necessary approvals etc

Deploy Stage:

Moving the software from Staging to Live Production environment. This stage includes setting up of infrastructure, servers' configuration, setting up of database etc

Differences

    Timings:

        Release happens before deployment. Software is release to users for UAT and then deployed to production.

    

    Activities:

        Release is about preparing for final deployment. deployment is the actual movement of software to production. 

--------------------------------------------------------------------------------------------------------------------------------------

Q4: What are the key components of Azure DevOps?

Answer:

1. Azure Boards: Agile tool for Kanban and Scrum boards. 

2. Azure Repo: Offers GIT repository. Code Source Control. 

       DevOps engineers usually store their ARM templates and Pipelines YAML files in Azure Repos. 

3. Azure Pipelines: CI (Continuous Integration and CD Continuous delivery to build, test, and deploy applications. 

4. Azure Test Plans: Tool for manual and automated testing. Continuous testing. This tool can be used to have a dashboard of test results that were executed as a part of pipeline. 

    -- It is a like a test management tool or a dashboard. 

    -- This is where you create and organize test cases, group them into test suites and plans, and track test execution status. It’s more about planning, traceability, and reporting than actually running the tests.

5. Azure Artifacts: This is a place for shared libraries and packages. In pipeline if a particular project is looking for package, it is advise to look here unless its a public nuget package to avoid any package conflict issues. 

--------------------------------------------------------------------------------------------------------------------------------------

Q5: Explain the structure of Dockerfile? Give dotnet 8 dockerfile example.

Answer:

Sometimes the Azure DevOps engineer has to create a Dockerfile for microservices if that is not already present in the base folder of the microservice.

Based on the technology of microservice dockerfile will be created. The steps will remain same for all technology, we just change the framework and build, deploy scripts. 

Base structure of Dockerfile typically include:

1. Base Image: The starting point of your Docker image, usually an official image from Docker Hub. It will be different for different technologies
2. Application Code: Your project’s source code.
3. Dependencies: Libraries and packages required by your application.
4. Configuration: Environment variables, configuration files, etc.
5. Build the Project.
6. Entrypoint: The command that runs when a container starts.

# Use the official .NET 8 SDK image as the base. The image includes SDK which is necessary for building the dotnet applications. 

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build

# Set the working directory (container term can be used). All future commands will run here. This is required to give isolation to our project. 

WORKDIR /source

 

# Copy Project Files and restore dependencies. Copy the csproj file to the above working directory/Container donated by .

COPY *.csproj .

 

 

# Copy all the project files to above Container donated by .

COPY . .

# Restore dependencies. restore command will restore the dependencies defined in project file

RUN dotnet restore

# Build the application. This builds the project in Release Configuration and outputs the results in "/app" directory.  

RUN dotnet publish -c Release -o /app

# Use the official .NET runtime image. This base image requires for runtime of application (earlier it was for build)

FROM mcr.microsoft.com/dotnet/aspnet:8.0

# Set the working directory same as output directory of project build

WORKDIR /app

# Copy the build output from /app folder to . current runtime folder

COPY --from=build /app .

# Expose the port

EXPOSE 80

# Run the application. Specifies the command to run the application.

ENTRYPOINT ["dotnet", "MyApp.dll"]

Share DevOps Experience

Q: Tell how is the pipeline setup done in your organization? Share real life experience. 

Q: Please tell me what you have done so far in DevOps. What all activity experience you have.

=====================================================================================

Q: Tell how is the pipeline setup done in your organization? Share real life experience. 

Answer: I build the answer after discussing with my friend Varun and Ravi. Here I will try to capture the real-life scenario.

So lets begin with the pushing code to GitHub repository 

Considering we have some Feature to be implemented. So below will the basic branching strategy we have in GitHub. 

1. Main Branch- CD pipeline will trigger on this code always. 

2. User Story branch

3. feature branch. 

=====================================================================================

Q: Please tell me what you have done so far in DevOps. What all activity experience you have.

Answer:

In my recent project, I got a chance to migrate the GIT repository to Azure repository. It was complete end to end setup of pipeline for that new project. 

Setting up of Project and Repositories

We had a project which was written in multiple languages. It was microservice based project. Microservice were written in python and dotnet. It was basically a voting application where users were supposed to vote against the medicines and Doctor in hospital. 

My Responsibility was to Create a CI for above project. 

1st I created Docker file for projects where docker file was not present. Docker file will be used for building and creating a publish project. 

2nd we created a project on Azure Devops portal i.e https://dev.azure.com*.

Then I import the code hosted GitHub to Azure Repos. Out of multiple cloned branches, I set the main branch as default branch by going to the branch option on the left. 

3rd important thing is creation of Azure Container Registry, Where my outfile code will be stored. 

Creating a CI Pipeline

So I start with creating a pipeline, I choose Azure Repo as source code. 

Then I choose the Template for pipeline "Build and push an image to Azure Container Registery"

There I fill the Template file with values of my pipeline Steps and Tasks. 

Here I put the trigger as well. 

For Agent: I crated our own VM. Then there was proper documentation on how to make a VM agent for CICD pipeline. So we have our VM as agent. So high level, we ssh to the ubuntu VM and is tall a package as mentioned on documentation. 

As we know CI pipeline can be built on trigger Pull request PR) or commit has been made. In our case it was on pull request PR. So, what happen when a developer raises a PR all steps like UT, Static Code analysis, build of application and integration happens and Review has to only do the analysis of code changes done. he then merges the code. 

When the PR is raised by Developer following CI will trigger.

1. Unit Test the changes, 

2. Do the Static Code analysis,

3. Build the application, 

4. Run the e2e integration test cases, 

when the PR will be merged following CI (2nd CI) will be trigger:

5. Create a docker image: I created a "Dockerfile" for project in which developer had not created it. This is the file required to make a docker image of code. I created that docker file in the root directory of the Microservice. 

6. Push the image to ACR (Azure Container Registry)

7. Usually this will trigger CD on a Dev/ QA test environment.

Creating a CD Pipeline

As a part of CD pipeline following job was done. 

1. Take the copy of software from ACR and deploy it on VMs or Azure Kubernetes cluster. 

* its different from https://portal.azure.com. 

My Other Blogs

• Angular 9 https://himanshugoel2018angular.blogspot.com/
• API https://himanshugoel2018webapi.blogspot.com/
• Azure DevOps https://himanshugoel2018azuredevops.blogspot.com/
• Azure http://himanshugoel2018azure.blogspot.com/
• Coding Questions https://himanshugoel2018coding.blogspot.com/
• C-Sharp https://himanshugoel2018csharp.blogspot.com/
• dotnet Core http://himanshugoel2018core.blogspot.com/
• HTML + CSS https://himanshugoel2018css.blogspot.com/
• JavaScript ES6 https://himanshugoel2018javascript.blogspot.com/
• Learning Habits https://himanshugoel2018learninghabit.blogspot.com/
• Learning Topics https://himanshugoel2018learningtopics.blogspot.com/
• Managerial https://himanshugoel2018managerial.blogspot.com/
• Microservices https://himanshugoel2018microservices.blogspot.com/
• Mongo DB https://himanshugoel2018mongodb.blogspot.com/
• MVC http://himanshugoel2018mvc.blogspot.com/
• Node JS https://himanshugoel2018nodejs.blogspot.com/
• Softmind http://softmindit.blogspot.com/
• SQL https://himanshugoel2018sql.blogspot.com/
• System Architect https://himanshugoel2018systemarchitect.blogspot.com/