← Back to Article List         
What is DevOps?

What is DevOps?

Published on 03 Oct 2026     10 min read Azure DevOps
Azure DevOps Fundamentals

DevOps and the DevOps Lifecycle

What is DevOps?

DevOps is a combination of Development (Dev) and Operations (Ops) practices that helps teams build, test, release, deploy, and operate software faster and more reliably.

Traditionally, developers and operations teams often worked separately:

Development Team
      ↓
Develop application
      ↓
Hand over to Operations
      ↓
Operations deploys application

This can create problems such as:

  • Slow releases
  • Manual deployment errors
  • "It works on my machine" issues
  • Poor communication between teams
  • Long feedback cycles
  • Difficulty identifying problems

DevOps encourages collaboration, automation, continuous feedback, and shared responsibility throughout the software lifecycle.

A modern DevOps flow looks more like:

Plan
  ↓
Develop
  ↓
Build
  ↓
Test
  ↓
Release
  ↓
Deploy
  ↓
Operate
  ↓
Monitor
  ↓
Feedback
  └────────→ Plan again

Main purpose

The main goal of DevOps is to deliver software:

  • Faster
  • More frequently
  • More consistently
  • With better quality
  • With less manual work
  • With faster feedback

DevOps is not simply a tool or Azure DevOps product. It is a combination of:

People + Process + Practices + Automation + Tools

Tools such as Azure DevOps, GitHub, Git, Docker, Kubernetes, Terraform, and Azure can help implement DevOps practices.


3. How Does DevOps Work?

Consider an ASP.NET Core application.

Step 1 — Plan

The team decides what needs to be developed.

For example:

Feature:
Add customer registration

Requirements, user stories, bugs, and tasks can be tracked using tools such as Azure Boards.

Step 2 — Develop

The developer writes the ASP.NET Core code.

Developer
   ↓
Creates feature branch
   ↓
Writes code
   ↓
Commits changes

For example:

git checkout -b feature/customer-registration
git add .
git commit -m "Add customer registration"

Step 3 — Source Control

The developer pushes the code to a Git repository such as Azure Repos or GitHub.

git push origin feature/customer-registration

Usually, the developer then creates a Pull Request (PR).

Feature Branch
      ↓
Pull Request
      ↓
Code Review
      ↓
main

Step 4 — Continuous Integration

After code is pushed or merged, a Continuous Integration (CI) pipeline can automatically:

Get source code
      ↓
Restore dependencies
      ↓
Build
      ↓
Run tests
      ↓
Create artifact

This quickly verifies that the application can be built and tested successfully.

Step 5 — Continuous Delivery/Deployment

The successfully built artifact moves through environments such as:

Artifact
   ↓
Development
   ↓
SIT
   ↓
UAT
   ↓
Production

Organizations may use approvals, automated tests, security checks, and other controls between environments.

Step 6 — Operate

After deployment, the application runs in the production environment.

For example:

ASP.NET Core Application
        ↓
Azure App Service

Operations activities can include scaling, configuration, reliability, backup, incident response, and infrastructure management.

Step 7 — Monitor

The team monitors:

  • Application availability
  • Errors/exceptions
  • Performance
  • Logs
  • CPU and memory
  • Request latency
  • Failed requests

Azure services such as Azure Monitor and Application Insights are commonly used.

Step 8 — Feedback

Monitoring information, incidents, customer feedback, and business feedback are used to improve the next development cycle.

That is why DevOps is normally represented as a continuous loop.


4. Simple Example / Syntax

A basic Azure Pipelines YAML file for an ASP.NET Core application could be:

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '8.x'

- script: dotnet restore
  displayName: 'Restore Dependencies'

- script: dotnet build --configuration Release --no-restore
  displayName: 'Build Application'

- script: dotnet test --configuration Release --no-build
  displayName: 'Run Tests'

- script: dotnet publish --configuration Release --output $(Build.ArtifactStagingDirectory)
  displayName: 'Publish Application'

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)'
    artifact: 'drop'

Explanation

trigger

trigger:
- main

The pipeline is automatically triggered when relevant changes are pushed to the main branch.

pool

pool:
  vmImage: 'ubuntu-latest'

Specifies the agent environment used to execute the pipeline.

Here, Microsoft-hosted Ubuntu infrastructure is used.

Install .NET SDK

- task: UseDotNet@2

Makes the required .NET SDK available to the pipeline.

Restore

dotnet restore

Downloads the NuGet packages required by the application.

Build

dotnet build

Compiles the application.

Test

dotnet test

Executes automated tests.

If important tests fail, the pipeline should normally fail rather than promote a bad build.

Publish

dotnet publish

Produces the deployable output of the ASP.NET Core application.

Publish Pipeline Artifact

- task: PublishPipelineArtifact@1

Stores the generated output as a pipeline artifact so that it can later be deployed.

The important concept is:

Code Change
    ↓
Pipeline Trigger
    ↓
Restore
    ↓
Build
    ↓
Test
    ↓
Publish
    ↓
Artifact

5. Practical Real-World Example

Suppose a team is developing an ASP.NET Core banking application.

A typical DevOps process could be:

Developer
   ↓
Feature Branch
   ↓
Write ASP.NET Core Code
   ↓
Commit
   ↓
Push to Azure Repos
   ↓
Create Pull Request
   ↓
Code Review + Branch Policies
   ↓
Merge into main
   ↓
CI Pipeline
   ↓
Restore
   ↓
Build
   ↓
Unit Tests
   ↓
Artifact
   ↓
Deployment Pipeline
   ↓
SIT
   ↓
UAT
   ↓
Approval
   ↓
Production
   ↓
Monitoring
   ↓
Feedback

Without DevOps automation, developers or operations engineers might manually build the application, copy files to servers, change configuration, and perform deployment steps.

With DevOps, many of these steps are automated and repeatable.


6. Important Concepts / Components

1. Continuous Integration (CI)

Developers frequently integrate code into a shared repository, and automated pipelines validate changes.

Typically:

Code → Build → Test → Artifact

The objective is to identify integration problems early.


2. Continuous Delivery

The application is kept in a deployable state, and deployment to production may require a manual approval or business decision.

For example:

Build
  ↓
Test
  ↓
Deploy UAT
  ↓
Manual Approval
  ↓
Production

3. Continuous Deployment

Successful changes can be automatically deployed all the way to production after required automated checks succeed.

Commit
   ↓
Build
   ↓
Test
   ↓
Deploy
   ↓
Production

No manual production approval is required in a fully continuous-deployment flow.


4. Version Control

Source code is maintained in a version-control system such as Git.

For example:

Azure Repos
GitHub

It provides history, branching, merging, collaboration, and traceability.


5. Infrastructure as Code (IaC)

Infrastructure is defined using code/configuration rather than being created manually.

Examples include:

  • Bicep
  • Terraform
  • ARM templates

For example:

IaC Code
   ↓
Pipeline
   ↓
Azure Resources

This makes infrastructure more repeatable and version-controlled.


6. Automation

Automation is one of the core DevOps principles.

Teams automate activities such as:

  • Builds
  • Tests
  • Deployments
  • Infrastructure provisioning
  • Security scanning
  • Monitoring and alerting

7. Monitoring and Feedback

DevOps does not finish when an application reaches production.

Teams continuously monitor production and use the information to improve the system.

Production
    ↓
Monitoring
    ↓
Feedback
    ↓
New Work

8. Collaboration

Development, QA, operations, security, and other teams collaborate rather than working as isolated silos.

DevOps therefore involves culture and process, not just technical automation.


7. Advantages

Faster software delivery

Automation reduces the time required to build, test, and deploy applications.

Frequent releases

Smaller changes can be released more frequently instead of waiting for large releases.

Better quality

Automated testing and CI help identify problems earlier.

Consistent deployments

Automated pipelines reduce differences caused by manual deployment procedures.

Faster feedback

Developers can quickly know whether their changes build and pass tests.

Better collaboration

Development and operations teams share responsibility for delivering and operating software.

Traceability

Organizations can track:

Requirement
   ↓
Code Change
   ↓
Commit / Pull Request
   ↓
Build
   ↓
Artifact
   ↓
Deployment

8. Disadvantages / Limitations

DevOps also has some practical challenges:

  • Initial setup can require significant effort.
  • Teams need knowledge of pipelines, cloud platforms, automation, security, and monitoring.
  • Poorly designed pipelines can become difficult to maintain.
  • Excessive permissions in pipelines or service connections create security risks.
  • Culture and organizational changes can be harder than implementing the tools themselves.
  • Automation still requires appropriate testing, approvals, and governance.

DevOps does not mean deploying everything immediately without controls.


9. DevOps Lifecycle

The exact lifecycle terminology can vary between organizations, but a common model is:

Stage Purpose
Plan Define requirements, user stories, tasks and bugs
Develop Write and review code
Build Compile/package the application
Test Validate quality and functionality
Release Prepare an approved version for deployment
Deploy Deploy to target environments
Operate Run and maintain the application
Monitor Observe health, performance and failures
Feedback Feed production/user information back into planning

The key point is that this is continuous:

          PLAN
           ↓
        DEVELOP
           ↓
         BUILD
           ↓
          TEST
           ↓
        RELEASE
           ↓
         DEPLOY
           ↓
        OPERATE
           ↓
        MONITOR
           ↓
        FEEDBACK
           │
           └────────→ PLAN

10. Key Points to Remember

  • DevOps = Development + Operations, but it also involves QA, security, and other stakeholders.
  • DevOps is a culture and set of practices, not merely a product.
  • Its main goals include automation, collaboration, faster feedback, reliability, and frequent delivery.
  • CI automatically builds and tests integrated code.
  • Continuous Delivery keeps software deployable; production deployment may remain a manual decision.
  • Continuous Deployment can automatically deploy successful changes to production.
  • Git provides source/version control.
  • Pipelines automate build, test, packaging, and deployment activities.
  • Artifacts are versioned outputs produced by the build process for deployment.
  • Infrastructure as Code automates infrastructure provisioning.
  • Monitoring and feedback are part of DevOps; deployment is not the end of the lifecycle.
  • Protect secrets such as passwords, API keys, certificates, and connection strings. Do not hard-code them into repositories or pipeline YAML.

11. Interview Questions and Answers

Q1. What is DevOps?

DevOps is a set of culture, practices, processes, and automation that improves collaboration between development and operations and helps teams build, test, release, deploy, and operate software faster and more reliably.


Q2. Why do we need DevOps?

DevOps helps reduce manual work, long release cycles, deployment errors, and communication gaps. It uses automation and continuous feedback to improve software delivery speed and reliability.


Q3. What are the main stages of the DevOps lifecycle?

A common lifecycle is:

Plan → Develop → Build → Test → Release
→ Deploy → Operate → Monitor → Feedback

The process repeats continuously.


Q4. Is Azure DevOps the same as DevOps?

No.

DevOps is a set of practices and culture.

Azure DevOps is Microsoft's platform providing services that help teams implement those practices, such as repositories, boards, pipelines, testing capabilities, and artifacts.


Q5. What is CI/CD?

CI (Continuous Integration) automatically integrates, builds, and tests code changes frequently.

CD can refer to Continuous Delivery or Continuous Deployment and focuses on reliably moving validated software toward or into target environments.


Q6. Where does Git fit into DevOps?

Git provides version control.

Developers use Git to maintain source history, work with branches, collaborate through pull requests, and provide the source changes that can trigger CI/CD pipelines.


Q7. What happens after a developer pushes code?

A typical flow is:

Push / Pull Request
      ↓
Code Review
      ↓
Merge
      ↓
CI Pipeline
      ↓
Build
      ↓
Automated Tests
      ↓
Artifact
      ↓
Deployment Pipeline
      ↓
Environment

The exact trigger and approval process depends on the team's pipeline and branch policies.


Q8. Your company performs deployments manually. How could DevOps improve the process?

I would first make the build repeatable, store the code in version control, introduce automated build and tests through CI, generate a versioned artifact, and then automate deployments through controlled pipelines. I would also use environment-specific configuration, secure secrets, approvals where required, and production monitoring.


12. Interview Answer

DevOps is a combination of culture, practices, processes, and automation that improves collaboration between development and operations teams. Its purpose is to deliver software faster and more reliably through automation and continuous feedback. The DevOps lifecycle commonly includes Plan, Develop, Build, Test, Release, Deploy, Operate, Monitor, and Feedback. CI/CD pipelines automate build, testing, and deployment activities. Tools such as Git, Azure Repos, Azure Pipelines, Infrastructure as Code, and monitoring services help implement DevOps practices.