How to Configure DevOps Pipelines: A Real-Time CI/CD Example

In moern software teams, DevOps pipelines are the backbone that connects code to production. Instead of manually building, testing, and deploying applications, we automate these steps into a smooth flow known as a CI/CD pipeline. This article explains what a DevOps pipeline is and walks through a real-time example you can use for your own projects.

---

What Is a DevOps Pipeline?

A DevOps pipeline is a series of automated steps that take your application from source code to a running, monitored service. It usually includes:

• Code: Developers push changes to a version control system like Git.

• Build: The pipeline compiles/assembles the application.

• Test: Automated tests run to catch bugs early.

• Release: Successful builds are packaged as deployable artifacts.

• Deploy: Artifacts are deployed to environments (dev, test, production).

• Monitor: Logs and metrics are collected to ensure the system is healthy.

When all these stages run automatically on every code change, you get Continuous Integration (CI) and Continuous Delivery/Deployment (CD).

---

Why Pipelines Matter in Real Projects

In a real-time project, multiple developers work on the same codebase. Without a pipeline:

• Builds may fail on one machine but not another.

• Manual deployments are error-prone and slow.

• Bugs reach production because tests are skipped.

With a CI/CD pipeline:

• Every push triggers a consistent build and test process.

• Deployments follow the same automated, repeatable steps.

• You get faster feedback and higher confidence in releases.

For teams building web applications, APIs, or microservices, a good pipeline is not optional—it is essential.

---

Real-Time Scenario: Web App CI/CD Pipeline

Let’s take a practical example you can relate to.

Imagine a small team building a Node.js web application. The code is stored in a Git repository. The team wants this behavior:

1. Developer pushes code to the main branch.

2. Pipeline automatically runs:

   • Install dependencies

   • Run unit tests

   • Build the application

3. If everything passes, the pipeline deploys the app to a cloud Web App (for example, Azure Web App or any similar platform).

4. The team can see logs and monitor the application after every deployment.

This is a classic real-time CI/CD pipeline scenario.

---

Designing the Pipeline Stages

To implement this behavior, we can design the pipeline with two main stages:

1. Build and Test (CI)

This stage should:

• Check out the latest code.

• Install required tools and dependencies.

• Run automated tests.

• Create a build output ready for deployment.

If any step fails, the pipeline should stop and notify the team.

2. Deploy (CD)

This stage should:

• Take the successful build artifact.

• Deploy it to the chosen environment (dev, test, or production).

• Optionally run post-deployment checks (smoke tests).

• Notify the team on success or failure.

Separating Build and Deploy stages makes it easier to control which environments receive which build.

---

Example Pipeline Configuration (YAML Style)

Many modern tools (Azure DevOps, GitHub Actions, GitLab CI, etc.) use YAML configuration files to define pipelines. Below is a simplified pipeline configuration that you can adapt for your own blog readers.

text
trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  appName: 'my-demo-webapp'
  environment: 'production'

stages:
- stage: Build
  displayName: 'Build and Test'
  jobs:
  - job: BuildJob
    steps:
    - checkout: self

    - task: NodeTool@0
      inputs:
        versionSpec: '18.x'
      displayName: 'Use Node.js 18'

    - script: |
        npm install
        npm test
        npm run build
      displayName: 'Install, test, and build'

    - task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: 'dist'
        includeRootFolder: false
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/drop.zip'
      displayName: 'Archive build output'

    - task: PublishBuildArtifacts@1
      inputs:
        pathtoPublish: '$(Build.ArtifactStagingDirectory)'
        artifactName: 'drop'
      displayName: 'Publish artifact'

- stage: Deploy
  displayName: 'Deploy to Production'
  dependsOn: Build
  jobs:
  - job: DeployJob
    steps:
    - download: current
      artifact: drop

    - script: |
        echo "Deploying $(appName) to $(environment) environment"
        # Replace this with your actual deploy command, e.g.:
        # az webapp deploy --name $(appName) --src-path "$(Pipeline.Workspace)/drop/drop.zip"
      displayName: 'Deploy application'

You can explain this YAML in your blog as follows:

• trigger ensures the pipeline runs on every push to main.

• pool defines the build agent (Ubuntu in this example).

• The Build stage:

  • Checks out code.

  • Uses Node.js 18.

  • Runs install, tests, and build.

  • Archives and publishes the build as an artifact.

• The Deploy stage:

  • Downloads the artifact.

  • Runs a deployment command (to a cloud platform or server).

---

How This Works in Real Time

In day-to-day development, this pipeline behaves like an automated assistant:

• A developer fixes a bug and pushes code.

• Within minutes, the pipeline:

  • Builds the app.

  • Runs tests.

  • Deploys a new version if everything passes.

• If a test fails, the pipeline stops and marks the run as failed.

• The team checks the pipeline logs, fixes the issue, and pushes again.

This continuous loop greatly reduces the risk of broken code reaching production and makes releases faster and safer.

---

Best Practices for DevOps Pipelines

To make your pipelines robust for real-world use, consider these practices:

• Keep pipelines fast: Slow pipelines reduce developer productivity.

• Fail early: Run quick linting and unit tests before long integration tests.

• Use separate environments: Deploy to dev, then test, then production with approvals.

• Add quality gates: Include code quality checks, security scans, and test coverage thresholds.

• Monitor everything: Collect logs and metrics from both pipelines and applications.

These small improvements add up to a professional, corporate-grade pipeline over time.

Angular Directives – Complete Guide with All Examples

 A Directive in Angular is a class that adds behavior to HTML elements or changes the structure of the DOM.

Think of a directive as an instruction to Angular.

For example:

• Show or hide an element

• Repeat an element

• Change colors

• Disable buttons

• Highlight text

• Apply validation

• Display content based on user role

---

Types of Directives

Angular has three types of directives.

Angular Directives

        │
        ├──────────────┐
        │              │
        ▼              ▼
Structural      Attribute
Directives      Directives
        │
        ▼
Component
(Technically a directive with a template)

Type	Purpose	Example
Component Directive	Creates a view (template)	<app-employee>
Structural Directive	Changes the DOM structure	*ngIf, *ngFor, *ngSwitch
Attribute Directive	Changes appearance or behavior	ngClass, ngStyle, custom directives

---

1. Component Directive

A component is actually a directive with its own HTML template.

Example:

@Component({
  selector: 'app-employee',
  template: `<h2>Employee Details</h2>`
})
export class EmployeeComponent { }

Use:

<app-employee></app-employee>

Output:

Employee Details

---

2. Structural Directives

Structural directives add or remove elements from the DOM.

They are written with *.

---

A. *ngIf

Displays an element only if the condition is true.

Example

isLoggedIn = true;

<div *ngIf="isLoggedIn">
    Welcome User
</div>

Output

Welcome User

If:

isLoggedIn = false;

Output

Nothing is displayed.

Real-Time Example

Internet Banking

User Logged In

↓

Dashboard Visible

Otherwise

Please Login

---

ngIf with else

<div *ngIf="isLoggedIn; else loginPage">
    Welcome User
</div>

<ng-template #loginPage>
    Please Login
</ng-template>

---

B. *ngFor

Used to repeat HTML.

Component

employees = [
  "Mahesh",
  "Ravi",
  "Priya",
  "Kiran"
];

HTML

<ul>
    <li *ngFor="let emp of employees">
        {{emp}}
    </li>
</ul>

Output

Mahesh
Ravi
Priya
Kiran

---

Real-Time Example

Employee List

Employee Table

↓

100 Employees

↓

*ngFor repeats rows

---

ngFor with Index

<li *ngFor="let emp of employees; let i=index">
    {{i+1}} - {{emp}}
</li>

Output

1 - Mahesh
2 - Ravi
3 - Priya

---

ngFor with first and last

<li *ngFor="let emp of employees;
            let first=first;
            let last=last">

{{emp}}

{{first}}

{{last}}

</li>

Output

Mahesh   true    false
Ravi     false   false
Priya    false   true

---

C. ngSwitch

Component

role = "Admin";

HTML

<div [ngSwitch]="role">

    <p *ngSwitchCase="'Admin'">
        Admin Dashboard
    </p>

    <p *ngSwitchCase="'Employee'">
        Employee Dashboard
    </p>

    <p *ngSwitchDefault>
        Invalid User
    </p>

</div>

Output

Admin Dashboard

---

Real-Time Example

Login

Admin

↓

Admin Dashboard

Employee

↓

Employee Dashboard

---

3. Attribute Directives

Attribute directives change appearance or behavior.

---

ngClass

Component

isActive = true;

HTML

<div
[ngClass]="{'active':isActive}">
Employee
</div>

CSS

.active{
color:red;
font-weight:bold;
}

Output

Employee (Red Color)

---

Real-Time Example

Employee Status

Active Employee

↓

Green Color

Inactive

↓

Gray Color

---

ngStyle

<div
[ngStyle]="{

'color':'blue',

'font-size':'25px'

}">
Employee
</div>

Output

Blue Employee

---

Real-Time Example

Bank Balance

If balance is low

<div
[ngStyle]="{
'color':
balance<1000?
'red':'green'
}">
{{balance}}
</div>

---

Built-in Attribute Directive Example

Disable Button

<button
[disabled]="isSaving">
Save
</button>

---

Custom Attribute Directive

Suppose HR wants every employee card highlighted on mouse hover.

Generate Directive

ng g directive highlight

highlight.directive.ts

import {
Directive,
ElementRef,
HostListener
} from '@angular/core';

@Directive({
selector:'[appHighlight]'
})
export class HighlightDirective{

constructor(
private element:ElementRef){}

@HostListener('mouseenter')

mouseEnter(){

this.element.nativeElement.style.backgroundColor="yellow";

}

@HostListener('mouseleave')

mouseLeave(){

this.element.nativeElement.style.backgroundColor="white";

}

}

Use

<div appHighlight>

Employee Card

</div>

Output

Mouse Hover

↓

Yellow Background

Mouse Leave

↓

White Background

---

Custom Permission Directive

<div *appHasRole="'Manager'">

Salary Details

</div>

Logic

if(role==="Manager")
{
show=true;
}

---

Real-Time Example

Employee Login

Role

↓

Employee

↓

Salary Hidden

Manager

↓

Salary Visible

---

Custom Disable Directive

<input appDisable />

Directive

this.element.nativeElement.disabled=true;

Output

Textbox Disabled

---

Real-Time Employee Portal

Employee Dashboard

        │
        ▼

*ngIf

Show Attendance

        │
        ▼

*ngFor

List Employees

        │
        ▼

ngClass

Green Active Employee

        │
        ▼

ngStyle

Salary Red

        │
        ▼

appHighlight

Hover Effect

        │
        ▼

appHasRole

Manager Only

---

Structural vs Attribute Directives

Feature	Structural Directive	Attribute Directive
Changes DOM	Yes	No
Adds/Removes Elements	Yes	No
Changes Style	No	Yes
Uses *	Yes	No
Examples	*ngIf, *ngFor, *ngSwitch	ngClass, ngStyle, appHighlight

---

Interview Questions

1. What is a directive in Angular?

A directive is a class that adds behavior to HTML elements or changes the DOM structure.

2. How many types of directives are there?

Three:

• Component Directives

• Structural Directives

• Attribute Directives

3. What is the difference between *ngIf and [hidden]?

*ngIf	[hidden]
Removes the element from the DOM when false	Keeps the element in the DOM but hides it using CSS

4. What is the difference between ngClass and ngStyle?

ngClass	ngStyle
Applies one or more CSS classes	Applies inline CSS styles

5. Can we create custom directives?

Yes. Angular allows you to create reusable custom directives using the @Directive decorator.

Note for Angular 17+: The examples above use the classic structural directives (*ngIf, *ngFor, *ngSwitch), which are still widely used. Angular 17 also introduced new built-in control flow syntax (@if, @for, and @switch) as a modern alternative. Many existing projects and interview questions still use the * syntax, so it's important to understand both.