What is DevOps?

The philosophy that bridges development and operations teams

The Core Idea

DevOps = Development + Operations. Traditionally, developers wrote code and "threw it over the wall" to operations teams who deployed it. This caused slow releases, blame games, and broken production systems.

DevOps is a culture, set of practices, and tools that breaks down these silos. The goal: ship software faster, more reliably, and with fewer failures.

💡 Think of DevOps like a restaurant kitchen: instead of chefs (devs) cooking and waitstaff (ops) serving separately with no communication, everyone works together — chefs understand what customers want, waitstaff understand what's being cooked.

The DevOps Infinity Loop

Plan

→

Code

→

Build

→

Test

→

Release

→

Deploy

→

Monitor

↩ feedback

Key Principles

🤝 Collaboration

Dev and Ops teams share responsibility for the entire software lifecycle

⚡ Automation

Automate testing, builds, deployments to remove human error and go faster

📊 Continuous Feedback

Monitor production constantly; feed insights back to developers immediately

🔄 Continuous Improvement

Small, frequent releases instead of large, risky deployments every 6 months

Popular DevOps Tools

Each phase of DevOps has dedicated tools:

Git (Code)Jenkins (CI/CD)Docker (Containerize)Kubernetes (Orchestrate)Terraform (Infrastructure)Prometheus (Monitor)Ansible (Config Mgmt)GitLab (All-in-one)

DevOps vs SDLC

Understanding the relationship — DevOps is not a replacement for SDLC

Side-by-Side Comparison

Aspect	SDLC	DevOps
Definition	A structured process to plan, create, test, and deliver software	A culture + practice that applies automation and collaboration to SDLC
Focus	Phases and deliverables	Speed, quality, and continuous delivery
Teams	Dev and Ops work separately	Dev and Ops work together
Release Cycle	Long cycles (months)	Short cycles (days/hours)
Feedback	After testing phase	Continuous, real-time monitoring
Testing	Dedicated test phase	Testing integrated throughout (CI)
Deployment	Manual, infrequent	Automated, frequent (CD)

Key Insight

DevOps does NOT replace SDLC. DevOps accelerates and improves SDLC by applying automation, collaboration tools, and continuous feedback to each SDLC phase. Think of SDLC as the "what to do" and DevOps as "how to do it better."

SDLC Phases (Traditional)

1. Plan

→

2. Analyze

→

3. Design

→

4. Implement

→

5. Test

→

6. Deploy

→

7. Maintain

DevOps Enhances Each Phase

Plan → Jira / GitHub Issues

Track tasks, sprints, and user stories collaboratively

Code → Git, GitHub, GitLab

Version control, code reviews, branching strategies

Test → Jenkins, Selenium

Automated unit, integration, regression tests on every commit

Deploy → Docker, Kubernetes

Containerized, automated, repeatable deployments

DevOps Life Cycle

8 phases that run continuously in a loop — never stopping

The 8 Phases

1. 📋 Plan

Define features, set sprint goals. Tools: Jira, Confluence, Trello. Teams align on what to build.

2. 💻 Code

Developers write code in feature branches. Code reviews happen before merging. Tools: Git, VS Code.

3. 🔨 Build

Source code is compiled/bundled into a runnable artifact. Tools: Maven, Gradle, npm, Docker.

4. 🧪 Test

Automated tests run: unit tests, integration tests, security scans. Tools: JUnit, Selenium, SonarQube.

5. 📦 Release

Tested artifact is tagged and prepared for deployment. This may include approval gates.

6. 🚀 Deploy

Release pushed to staging then production. Tools: Kubernetes, Ansible, Terraform, Jenkins.

7. ⚙️ Operate

System runs in production. Ops team manages infrastructure, scaling, and uptime.

8. 📊 Monitor

Track performance, errors, user behavior. Tools: Prometheus, Grafana, ELK Stack, Datadog.

Why "Continuous"?

In traditional models, you finish each phase completely before moving to the next. In DevOps, these phases run in tight, overlapping cycles. A team might be planning sprint 5, coding sprint 4, and monitoring sprint 3 — all simultaneously. This is the power of DevOps: nothing ever stops.

Real Example: Feature Shipping Timeline

Traditional	DevOps
Plan: 2 weeks	Plan: 2 days (rolling)
Code: 3 months	Code: 1–2 week sprints
Test: 1 month	Test: Automated, runs in minutes
Deploy: Once every 6 months	Deploy: Multiple times per day
Total: ~6 months	Total: 1–2 weeks per feature

Version Control & Basic Git Commands

Git is the foundation of all modern DevOps workflows

What is Version Control?

Version control tracks every change to your code. Think of it like Google Docs "version history" but for entire projects. You can: see who changed what, revert to any past state, work on features in parallel (branching), and merge everyone's work safely.

Essential Git Commands

# Setup — first time only
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Start a new project
git init                    # create a new repo in current folder
git clone <url>             # download an existing repo from GitHub

# Everyday workflow
git status                  # see what files changed
git add .                   # stage ALL changed files
git add index.html          # stage ONE specific file
git commit -m "Add login page"  # save staged changes with a message
git push origin main        # upload commits to GitHub/GitLab
git pull origin main        # download latest changes from remote

# Branching — work on features safely
git branch feature/login    # create new branch
git checkout feature/login  # switch to that branch
git checkout -b feature/pay # create AND switch in one command
git merge feature/login     # merge branch into current branch

# History & inspection
git log --oneline           # compact history view
git diff                    # show unstaged changes
git stash                   # temporarily hide your changes
git stash pop               # bring them back

Git Branching Strategy (GitFlow)

main ────────────────────────────────── (production code)

develop ──────────────────────────────── (latest dev code)

feature/login ────── merge → develop ──── (new feature)

hotfix/crash ─── merge → main+develop ──── (emergency fix)

Merge Conflicts

When two people edit the same line, Git shows a conflict. Resolve it by editing the file, removing the conflict markers (<<<< and >>>>), then committing. Tools like VS Code have visual conflict resolution built-in.

SDLC & DevOps — In Which Scenario?

When to use SDLC models, when DevOps applies, and how they overlap

When to Use Which?

Scenario	Best Approach	Why
Banking system, safety-critical software	Waterfall + strict SDLC	Requirements don't change; compliance needed
Startup building a product	Agile SDLC + DevOps CI/CD	Rapid iteration, fast feedback from users
Large team, multiple services	DevOps + Microservices	Each team deploys independently
E-commerce platform	DevOps + Agile	Daily releases, A/B testing, monitoring
Government project	Waterfall SDLC	Fixed budget, fixed scope, approval gates

DevOps in Real Scenarios

🛒 Amazon

Deploys code every 11 seconds. Uses DevOps + microservices. Each team owns their service end-to-end.

🎬 Netflix

Deploys hundreds of times per day. Uses chaos engineering to test resilience in production.

🚀 Facebook

"Move fast and break things" — evolved to "move fast with stable infrastructure" using DevOps.

🏦 Banks

Still use traditional SDLC for core systems but adopt DevOps for customer-facing apps.

What is CI/CD?

Continuous Integration + Continuous Delivery/Deployment — the heart of DevOps

Three Concepts

CI — Continuous Integration

Developers merge code frequently (multiple times a day). Each merge triggers automated builds and tests. Catch bugs early, before they pile up.

CD — Continuous Delivery

Every passing build is automatically prepared for release to staging. A human presses "deploy to production" when ready.

CD — Continuous Deployment

Goes one step further — every passing build is automatically deployed to production with NO human intervention. Used by mature teams with excellent test coverage.

CI/CD Pipeline Stages

Source
git push

→

Build
compile

→

Unit Test
JUnit

→

Code Analysis
SonarQube

→

Package
Docker image

→

Deploy Staging
auto

→

Deploy Prod
auto/manual

Jenkinsfile — Pipeline as Code

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
        stage('Docker Build') {
            steps {
                sh 'docker build -t myapp:latest .'
            }
        }
        stage('Deploy') {
            steps {
                sh 'kubectl apply -f deployment.yaml'
            }
        }
    }
}

Poll SCM in Jenkins

How Jenkins watches your Git repository for changes

What is Poll SCM?

Poll SCM is a Jenkins trigger that checks your source code repository (Git/SVN) on a schedule. If new commits are found since the last check, Jenkins automatically starts a build. It's like setting an alarm to "check if anything new happened."

Cron syntax: H/5 * * * * means "check every 5 minutes." Jenkins uses cron format for scheduling.

Poll SCM vs Webhooks

Poll SCM	Webhook (Push Trigger)
Jenkins asks Git: "Any changes?" every N minutes	Git tells Jenkins: "New commit just happened!"
Slight delay (up to N minutes)	Instant trigger
Works behind firewalls	Git server needs to reach Jenkins
Creates unnecessary API calls	Efficient — only triggers when needed
Use when webhooks aren't possible	Preferred for public-facing Jenkins

Cron Syntax Explained

# Format: MINUTE HOUR DAY MONTH DAY_OF_WEEK
H/5 * * * *    # every 5 minutes
H * * * *      # once per hour
H/30 * * * *   # every 30 minutes
H 9 * * 1-5    # 9 AM every weekday
@midnight      # once a day at midnight

# 'H' = Jenkins picks a random minute in range
# This spreads load across multiple jobs

Second Phase of SDLC

The Requirements / System Analysis phase

What is the Second Phase?

The second phase of SDLC is Requirements Analysis (also called System Analysis). After the initial planning, this phase digs deep into what the system must do. Business analysts, stakeholders, and developers gather, document, and validate requirements.

Activities in This Phase

Feasibility Study

Is the project technically, financially, and legally possible?

Requirement Gathering

Interviews, surveys, workshops with stakeholders to understand needs

SRS Document

Software Requirements Specification — the official document of what must be built

Use Case Diagrams

Visual representation of how users interact with the system

Functional vs Non-Functional Requirements

Functional	Non-Functional
What the system does	How well it does it
"User can log in with email/password"	"Login must complete in under 2 seconds"
"Admin can delete accounts"	"System must handle 10,000 users simultaneously"
"System sends email on order"	"99.9% uptime required"

What is TDD?

Test-Driven Development — write tests BEFORE writing code

The TDD Cycle: Red → Green → Refactor

🔴 RED
Write a failing test

→

🟢 GREEN
Write min code to pass

→

🔵 REFACTOR
Clean up the code

↩

TDD Example in Python

# Step 1: RED — Write the test first (it will FAIL)
import unittest

class TestCalculator(unittest.TestCase):
    def test_add(self):
        result = add(2, 3)
        self.assertEqual(result, 5)  # FAILS — add() doesn't exist yet

# Step 2: GREEN — Write minimal code to make test pass
def add(a, b):
    return a + b    # Now the test passes ✓

# Step 3: REFACTOR — Improve without breaking the test
def add(*args):
    return sum(args)  # Supports more than 2 numbers

Benefits of TDD

Better Design

Writing tests first forces you to think about API design from the caller's perspective

Safety Net

Existing tests catch regressions when you change code later

Documentation

Tests serve as living documentation showing exactly how code should behave

Confidence

Refactor fearlessly — if tests pass, code works correctly

4th Stage of Scrum

Sprint Review — demonstrating what was built

Scrum Framework Overview

1. Sprint Planning
What to build

→

2. Sprint
1-4 weeks

→

3. Daily Scrum
15-min standup

→

4. Sprint Review
Demo to stakeholders

→

5. Retrospective
Improve process

The 4th Stage: Sprint Review

At the end of each sprint, the team demonstrates the working software to stakeholders (product owners, customers, management). This is NOT a status report — it's a live demo of working features.

Who attends?

Scrum team + Product Owner + key stakeholders + possibly customers

Duration

Max 4 hours for a 4-week sprint (1 hour per week of sprint)

What happens?

Team demos completed items, stakeholders give feedback, product backlog is updated

Output

Updated product backlog, insights for next sprint planning, stakeholder alignment

Scrum Roles

Role	Responsibility
Product Owner	Manages product backlog, prioritizes features, represents business
Scrum Master	Facilitates process, removes blockers, coaches team on Scrum
Development Team	Cross-functional team that designs, builds, and tests the product

Kubernetes Architecture

The brain and muscles of container orchestration

Two Types of Nodes

🧠 Control Plane (Master Node)

The brain. Makes all decisions: where to run containers, how many replicas, handling failures. Components: API Server, Scheduler, Controller Manager, etcd.

💪 Worker Nodes

The muscles. Actually run your containers. Each worker has: Kubelet (talks to master), Kube-proxy (networking), Container Runtime (Docker/containerd).

Control Plane Components

Component	Role
API Server	Front door to K8s. All commands (kubectl) go through it. REST API.
etcd	Distributed key-value store. The "database" of cluster state. Source of truth.
Scheduler	Decides WHICH worker node to run a new Pod on based on resources
Controller Manager	Watches for desired vs actual state. If 3 replicas needed but only 2 running, it creates one more.

Key Kubernetes Objects

# Pod — smallest deployable unit (1+ containers)
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app
    image: nginx:1.21
    ports:
    - containerPort: 80

---
# Deployment — manages multiple Pod replicas
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3          # run 3 copies
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-image:1.0

What is Kubernetes?

Container orchestration platform — the OS for your containers

The Core Problem It Solves

Docker lets you run ONE container. But in production, you might need 100 containers, across 10 servers, with automatic restarts when they crash, load balancing between them, and zero-downtime updates. Managing this manually is impossible. Kubernetes automates all of it.

Think of Docker as individual shipping containers, and Kubernetes as the entire port — cranes, trucks, schedules — that manages thousands of containers automatically.

What Kubernetes Does Automatically

Self-Healing

If a container crashes, K8s restarts it. If a node fails, pods move to healthy nodes.

Auto-Scaling

HPA (Horizontal Pod Autoscaler) adds/removes pods based on CPU/memory usage.

Load Balancing

Distributes traffic across all healthy pods using Services.

Rolling Updates

Update containers with zero downtime — gradually replace old pods with new ones.

Secret Management

Store passwords, API keys, certificates securely as K8s Secrets.

Storage Orchestration

Automatically mount storage from cloud, NFS, or local disks.

Essential kubectl Commands

kubectl get pods                     # list all pods
kubectl get nodes                    # list all nodes
kubectl apply -f deployment.yaml     # create/update resources
kubectl delete pod my-pod            # delete a pod
kubectl logs my-pod                  # view pod logs
kubectl exec -it my-pod -- bash      # shell into a pod
kubectl scale deploy my-app --replicas=5  # scale up
kubectl rollout status deploy/my-app # check update status

What is Jenkins?

The most popular open-source CI/CD automation server

Jenkins in Simple Terms

Jenkins is an open-source automation server written in Java. It watches your Git repo, and whenever you push code it automatically builds, tests, and deploys your application. Think of Jenkins as a robot developer that never sleeps — it runs your pipeline 24/7.

💡 Jenkins was originally called "Hudson" (created at Sun Microsystems in 2004). After Oracle acquired Sun, the community forked it and renamed it Jenkins in 2011. Today it has 1,800+ plugins.

Key Features

🔌 1800+ Plugins

Integrates with Git, Docker, Kubernetes, Slack, AWS, SonarQube, and almost every DevOps tool.

📜 Pipeline as Code

Define your entire CI/CD pipeline in a Jenkinsfile stored in your repo — versioned with your code.

🌐 Distributed Builds

Master-agent architecture lets you run builds on multiple machines in parallel.

🆓 Free & Open Source

No licensing cost. Large community, extensive documentation, runs on any OS.

Simple Jenkinsfile

pipeline {
    agent any
    environment {
        APP_NAME = 'my-app'
    }
    stages {
        stage('Checkout') {
            steps { git 'https://github.com/user/repo.git' }
        }
        stage('Build') {
            steps { sh 'mvn clean package -DskipTests' }
        }
        stage('Test') {
            steps { sh 'mvn test' }
            post { always { junit 'target/surefire-reports/*.xml' } }
        }
        stage('Deploy') {
            when { branch 'main' }
            steps { sh './deploy.sh' }
        }
    }
    post {
        failure { slackSend message: "Build FAILED: ${env.JOB_NAME}" }
        success { slackSend message: "Build PASSED ✓" }
    }
}

Jenkins Architecture

Master-Agent model for distributed, scalable builds

Master-Agent Architecture

🧠 Jenkins Master
Schedules, UI, config

⇄

Agent 1
Linux builds

Agent 2
Windows builds

Agent 3
Docker builds

Master vs Agent Responsibilities

Jenkins Master	Jenkins Agent
Hosts the web UI	Executes the actual build steps
Stores configuration & job history	Has the build tools (Maven, Node, Docker)
Schedules jobs & triggers	Reports results back to master
Manages plugins	Can be any OS / cloud VM / container
Should NOT run heavy builds	Scales horizontally — add more as needed

Agent Configuration in Jenkinsfile

pipeline {
    agent { label 'linux' }      // run on agent tagged 'linux'

    stages {
        stage('Build on Docker') {
            agent {
                docker { image 'maven:3.9-eclipse-temurin-17' }
            }
            steps { sh 'mvn package' }
        }
        stage('Deploy') {
            agent { label 'prod-agent' }
            steps { sh './deploy.sh' }
        }
    }
}

V-Model

Verification & Validation model — testing planned at every development stage

The V-Shape Explained

Requirements ──────────────────────── Acceptance Testing

System Design ──────────────── System Testing

Architecture Design ──────── Integration Testing

Module Design ──────── Unit Testing

↓ Coding ↓

Left Side vs Right Side

Left Side (Development)	Right Side (Testing)
Requirements Analysis	Acceptance Testing (UAT)
System Design	System Testing
Architecture Design	Integration Testing
Module Design	Unit Testing
Coding (bottom of V)	← connects both sides

When to Use V-Model

✅ Good For

Safety-critical systems (medical devices, aviation), projects with fixed, well-understood requirements, small-to-medium projects.

❌ Not Good For

Projects with changing requirements, long-running projects, when early prototypes are needed, or when budget/timeline is uncertain.

Key advantage over Waterfall: testing is planned in parallel with development. You don't wait until coding is done to think about tests — each dev phase has a corresponding test phase designed upfront.

Waterfall Model

The original sequential SDLC — each phase must complete before the next begins

Sequential Phases

1. Requirements — gather ALL requirements upfront

↓

2. System Design — architecture, DB schema, UI wireframes

↓

3. Implementation — developers write code

↓

4. Testing — QA team tests the complete system

↓

5. Deployment — release to production

↓

6. Maintenance — bug fixes, updates

Pros & Cons

Advantages	Disadvantages
Simple, easy to understand and manage	No working software until late in the project
Well-documented at every phase	Very expensive to go back and fix requirements
Works well for fixed-scope projects	Customer sees product only at the end
Clear milestones and deliverables	High risk — bugs found late are costly
Good for government/compliance projects	Not suitable for complex or evolving projects

Real-World Analogy

Building a house uses Waterfall: you can't pour the foundation after the roof is built. Requirements (blueprints) must be 100% complete before construction starts. This works for houses — but software requirements change constantly, which is why Agile was invented.

Agile Model

Iterative, incremental development with continuous customer feedback

Agile vs Waterfall Mindset

Waterfall	Agile
Plan everything upfront	Plan just enough, adapt as you go
Deliver once at the end	Deliver working software every 2–4 weeks
Customer sees product at the end	Customer involved throughout
Change is expensive	Change is welcomed and expected
Documentation-heavy	Working software over documentation

The Agile Manifesto (4 Values)

Individuals & Interactions

Over processes and tools — people matter more than rigid workflows

Working Software

Over comprehensive documentation — ship something that works

Customer Collaboration

Over contract negotiation — involve the customer constantly

Responding to Change

Over following a plan — embrace change even late in development

Agile Sprint Cycle

Backlog
User stories

→

Sprint Plan
Pick stories

→

Sprint
2–4 weeks

→

Review
Demo

→

Retro
Improve

↩ repeat

Scrum Model

The most widely used Agile framework — structured sprints with defined roles

Scrum Roles

🧑‍💼 Product Owner

Owns the product backlog. Prioritizes features by business value. The voice of the customer. Decides WHAT gets built.

🏃 Scrum Master

Servant-leader. Removes blockers, facilitates ceremonies, coaches team on Scrum. NOT a project manager.

👩‍💻 Development Team

Self-organizing, cross-functional team of 3–9 people. Includes developers, testers, designers. Decides HOW to build. Collectively owns the sprint goal.

Scrum Artifacts

Artifact	Description
Product Backlog	Ordered list of ALL features, bugs, and improvements. Owned by Product Owner.
Sprint Backlog	Subset of product backlog items the team commits to in one sprint.
Increment	The working, potentially shippable product at the end of each sprint.
Definition of Done	Team's agreed checklist: coded + tested + reviewed + deployed to staging = Done.

Scrum Ceremonies

Sprint Planning

Team selects backlog items for the sprint and breaks them into tasks. Time-boxed: 8 hrs max for 4-week sprint.

Daily Scrum (Standup)

15-minute daily sync. Three questions: What did I do? What will I do? Any blockers?

Sprint Review

Demo working software to stakeholders. Inspect the increment and adapt the backlog.

Sprint Retrospective

Team reflects: What went well? What to improve? Action items for next sprint.

CI/CD Pipeline with Jenkins

End-to-end automated pipeline from code commit to production deployment

Full Pipeline Flow

Git Push
trigger

→

Checkout
clone repo

→

Build
mvn package

→

Test
JUnit/Selenium

→

Docker Build
image push

→

K8s Deploy
kubectl apply

Production-Ready Jenkinsfile

pipeline {
    agent any
    environment {
        IMAGE = "myrepo/myapp:${BUILD_NUMBER}"
        REGISTRY_CREDS = credentials('dockerhub-creds')
    }
    stages {
        stage('Checkout') {
            steps { checkout scm }
        }
        stage('Build & Test') {
            steps { sh 'mvn clean verify' }
            post { always { junit '**/surefire-reports/*.xml' } }
        }
        stage('Code Quality') {
            steps {
                withSonarQubeEnv('SonarQube') {
                    sh 'mvn sonar:sonar'
                }
            }
        }
        stage('Docker Build & Push') {
            steps {
                sh "docker build -t ${IMAGE} ."
                sh "docker push ${IMAGE}"
            }
        }
        stage('Deploy to K8s') {
            steps {
                sh "kubectl set image deploy/myapp myapp=${IMAGE}"
                sh "kubectl rollout status deploy/myapp"
            }
        }
    }
}

Make Use of Kubernetes

Practical patterns — Services, ConfigMaps, HPA, and Namespaces

Kubernetes Service Types

Type	Use Case	Access
ClusterIP	Internal communication between pods	Only inside cluster
NodePort	Expose app on a static port on each node	External via NodeIP:Port
LoadBalancer	Production external access via cloud LB	Public IP from cloud provider
Ingress	HTTP routing, SSL termination, path-based routing	Domain-based external access

HPA — Auto-Scale Based on CPU

# Horizontal Pod Autoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60   # scale up if CPU > 60%

ConfigMap & Secret

# ConfigMap — non-sensitive config
kubectl create configmap app-config \
  --from-literal=DB_HOST=postgres \
  --from-literal=APP_PORT=8080

# Secret — sensitive data (base64 encoded)
kubectl create secret generic db-secret \
  --from-literal=DB_PASS=mysecretpassword

# Use in deployment
env:
- name: DB_HOST
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: DB_HOST
- name: DB_PASS
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: DB_PASS

What is GitLab?

All-in-one DevOps platform — Git hosting + CI/CD + registry + monitoring

GitLab vs GitHub vs Jenkins

Feature	GitLab	GitHub	Jenkins
Git Hosting	✅	✅	❌
Built-in CI/CD	✅ GitLab CI	✅ Actions	✅ (dedicated)
Container Registry	✅ Built-in	✅ GHCR	❌
Self-hosted option	✅ Free	✅ Enterprise	✅ Free
Issue tracking	✅ Built-in	✅ Built-in	❌
Best for	Full DevOps in one tool	Open source community	Complex pipelines

GitLab CI Pipeline (.gitlab-ci.yml)

# .gitlab-ci.yml — lives in your repo root
stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  image: maven:3.9-eclipse-temurin-17
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths: [target/*.jar]

test-job:
  stage: test
  script:
    - mvn test
  coverage: '/Total.*?([0-9]{1,3})%/'

deploy-job:
  stage: deploy
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - main

GitLab Key Features

🔒 Built-in Security

SAST, DAST, dependency scanning, secret detection — all built into the CI pipeline.

📦 Package Registry

Host npm, Maven, PyPI, Docker packages privately alongside your code.

🌍 GitLab Pages

Deploy static websites directly from your repo — like GitHub Pages.

🔁 Auto DevOps

Auto-detect language and configure a full CI/CD pipeline with zero configuration.

Version Control Types

Local, Centralized, and Distributed — how code history is stored and shared

Three Types

1. Local VCS

History stored only on your machine. Example: RCS. Simple but no collaboration — if your disk dies, history is gone.

2. Centralized VCS (CVCS)

Single central server holds all history. Examples: SVN, CVS. Everyone checks out from one place. Single point of failure.

3. Distributed VCS (DVCS)

Every developer has a full copy of the entire repository history. Examples: Git, Mercurial. Work offline, no single point of failure, fast branching. This is what Git uses.

CVCS vs DVCS

Centralized (SVN)	Distributed (Git)
One central repo	Every clone IS a full repo
Need network to commit	Commit offline, push later
Branching is slow/expensive	Branching is instant and cheap
Server failure = no work	Any clone can restore the repo
Simpler mental model	More powerful, slightly more complex

Why Git Won

Git was created by Linus Torvalds in 2005 for Linux kernel development. It needed to handle thousands of contributors, massive codebases, and work offline. Its distributed model, speed, and powerful branching made it the universal standard. Today 90%+ of developers use Git.

Jenkins Image Commands

Docker commands to run, manage, and configure Jenkins as a container

Run Jenkins in Docker

# Pull the official Jenkins LTS image
docker pull jenkins/jenkins:lts

# Run Jenkins — expose UI on port 8080, agents on 50000
docker run -d \
  --name jenkins \
  -p 8080:8080 \
  -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts

# Get the initial admin password
docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

# View Jenkins logs
docker logs -f jenkins

# Stop / Start / Remove
docker stop jenkins
docker start jenkins
docker rm -f jenkins

Jenkins with Docker-in-Docker (DinD)

# Run Jenkins that can also run Docker commands inside pipelines
docker run -d \
  --name jenkins \
  -p 8080:8080 \
  -v jenkins_home:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \
  jenkins/jenkins:lts

# Install Docker CLI inside Jenkins container
docker exec -u root jenkins \
  apt-get install -y docker.io

# Verify Docker works inside Jenkins
docker exec jenkins docker ps

Useful Jenkins Container Commands

# Backup Jenkins home directory
docker cp jenkins:/var/jenkins_home ./jenkins-backup

# Upgrade Jenkins image
docker pull jenkins/jenkins:lts
docker stop jenkins && docker rm jenkins
docker run -d --name jenkins -p 8080:8080 \
  -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts

# Check Jenkins version
docker exec jenkins jenkins --version

Jenkins Maven Project

Build, test, and package a Java Maven app with Jenkins end-to-end

Maven Project Structure

my-app/
├── pom.xml                  # Maven config — dependencies, plugins
├── src/
│   ├── main/java/           # Application source code
│   │   └── App.java
│   └── test/java/           # JUnit test classes
│       └── AppTest.java
└── Jenkinsfile              # Pipeline definition

pom.xml Essentials

<project>
  <groupId>com.example</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0.0</version>
  <packaging>jar</packaging>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.13.2</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Maven Lifecycle Commands

mvn validate        # check pom.xml is correct
mvn compile         # compile source code → target/classes
mvn test            # run unit tests
mvn package         # create JAR/WAR → target/my-app-1.0.0.jar
mvn verify          # run integration tests
mvn install         # install artifact to local ~/.m2 repo
mvn deploy          # upload to remote Nexus/Artifactory
mvn clean package   # delete target/ then package fresh
mvn clean verify -DskipTests  # skip tests for faster build

Jenkins Pipeline for Maven

pipeline {
    agent any
    tools { maven 'Maven-3.9' }   // configured in Jenkins Global Tools
    stages {
        stage('Build')   { steps { sh 'mvn clean package -DskipTests' } }
        stage('Test')    { steps { sh 'mvn test' } }
        stage('Archive') {
            steps { archiveArtifacts artifacts: 'target/*.jar' }
        }
    }
    post { always { junit 'target/surefire-reports/*.xml' } }
}

Git & Kubernetes Commands

Quick-reference cheatsheet for daily DevOps work

Git Cheatsheet

## SETUP
git config --global user.name "Name"
git config --global user.email "email@example.com"

## REPO
git init                        # new local repo
git clone <url>                 # clone remote repo
git remote -v                   # show remotes

## STAGING & COMMITTING
git status                      # what changed?
git add .                       # stage all
git commit -m "message"        # commit
git commit --amend              # edit last commit

## BRANCHING
git branch -a                   # list all branches
git checkout -b feature/x       # create + switch
git merge feature/x             # merge into current
git rebase main                 # rebase onto main
git branch -d feature/x         # delete branch

## REMOTE
git push origin main            # push to remote
git pull --rebase               # pull + rebase
git fetch --all                 # fetch all remotes

## UNDO
git revert HEAD                 # safe undo (new commit)
git reset --hard HEAD~1         # dangerous: delete last commit
git stash && git stash pop      # temp save/restore

Kubernetes Cheatsheet

## CLUSTER INFO
kubectl cluster-info
kubectl get nodes -o wide

## PODS
kubectl get pods -A             # all namespaces
kubectl describe pod <name>     # detailed info
kubectl logs <pod> -f           # stream logs
kubectl exec -it <pod> -- bash  # shell access
kubectl delete pod <name>       # delete (will restart)

## DEPLOYMENTS
kubectl apply -f deploy.yaml
kubectl rollout status deploy/<name>
kubectl rollout undo deploy/<name>   # rollback
kubectl scale deploy <name> --replicas=5

## SERVICES & INGRESS
kubectl get svc
kubectl expose deploy <name> --port=80 --type=LoadBalancer

## NAMESPACES
kubectl create namespace staging
kubectl get all -n staging

Flask App — DevOps Deployment

Build, containerize, and deploy a Python Flask app with CI/CD

Minimal Flask App

# app.py
from flask import Flask, jsonify
app = Flask(__name__)

@app.route('/')
def home():
    return jsonify({"status": "ok", "app": "flask-devops"})

@app.route('/health')
def health():
    return jsonify({"healthy": True}), 200

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Dockerfile for Flask

# Dockerfile
FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
EXPOSE 5000

CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

Kubernetes Deployment for Flask

apiVersion: apps/v1
kind: Deployment
metadata: {name: flask-app}
spec:
  replicas: 3
  selector: {matchLabels: {app: flask-app}}
  template:
    metadata: {labels: {app: flask-app}}
    spec:
      containers:
      - name: flask-app
        image: myrepo/flask-app:1.0
        ports: [{containerPort: 5000}]
        livenessProbe:
          httpGet: {path: /health, port: 5000}
          initialDelaySeconds: 10
---
apiVersion: v1
kind: Service
metadata: {name: flask-svc}
spec:
  selector: {app: flask-app}
  ports: [{port: 80, targetPort: 5000}]
  type: LoadBalancer

CI/CD Step-by-Step

Complete walkthrough — from zero to a working automated pipeline

Step-by-Step Setup

Step 1 — Install Jenkins

Run Jenkins via Docker or install on a server. Access UI at localhost:8080. Install suggested plugins.

Step 2 — Connect Git Repo

In Jenkins: New Item → Pipeline → configure GitHub repo URL + credentials. Enable webhook or Poll SCM.

Step 3 — Write Jenkinsfile

Add a Jenkinsfile to your repo root. Define stages: Checkout → Build → Test → Docker → Deploy.

Step 4 — Configure Tools

In Jenkins Global Tools: add JDK, Maven, Node.js versions. Jenkins auto-installs them on agents.

Step 5 — Add Credentials

Jenkins → Manage → Credentials: add DockerHub login, K8s kubeconfig, SSH keys securely.

Step 6 — First Build

Push a commit. Jenkins triggers automatically. Watch the pipeline stages turn green one by one.

Complete End-to-End Jenkinsfile

pipeline {
    agent any
    environment {
        DOCKER_IMAGE = "myrepo/myapp:${BUILD_NUMBER}"
    }
    stages {
        stage('Checkout')  { steps { checkout scm } }
        stage('Build')     { steps { sh 'mvn clean package -DskipTests' } }
        stage('Test')      {
            steps { sh 'mvn test' }
            post  { always { junit '**/surefire-reports/*.xml' } }
        }
        stage('Docker')    {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'dockerhub',
                    usernameVariable: 'USER',
                    passwordVariable: 'PASS')]) {
                    sh "docker login -u $USER -p $PASS"
                    sh "docker build -t ${DOCKER_IMAGE} ."
                    sh "docker push ${DOCKER_IMAGE}"
                }
            }
        }
        stage('Deploy')    {
            steps {
                sh "kubectl set image deploy/myapp myapp=${DOCKER_IMAGE}"
                sh "kubectl rollout status deploy/myapp"
            }
        }
    }
    post {
        success { echo 'Pipeline succeeded!' }
        failure { echo 'Pipeline failed — check logs' }
    }
}

Jenkins & Automated Testing

Integrate unit, integration, and code quality tests into your Jenkins pipeline

Types of Automated Tests in CI

Test Type	Tool	When in Pipeline	Speed
Unit Tests	JUnit, pytest, Jest	After every commit	Seconds
Integration Tests	Testcontainers, REST-assured	After build	Minutes
Code Coverage	JaCoCo, Istanbul	With unit tests	Seconds
Code Quality	SonarQube, Checkstyle	After tests	Minutes
E2E / UI Tests	Selenium, Cypress, Playwright	Staging deploy	Minutes–Hours
Security Scan	OWASP, Trivy, Snyk	Before deploy	Minutes

Jenkins Pipeline with Full Test Suite

pipeline {
    agent any
    stages {
        stage('Unit Tests') {
            steps { sh 'mvn test' }
            post { always { junit '**/surefire-reports/*.xml' } }
        }
        stage('Code Coverage') {
            steps { sh 'mvn jacoco:report' }
            post { always {
                jacoco execPattern: '**/jacoco.exec',
                       minimumLineCoverage: '80'
            }}
        }
        stage('SonarQube') {
            steps {
                withSonarQubeEnv('SonarQube') { sh 'mvn sonar:sonar' }
            }
        }
        stage('Security Scan') {
            steps {
                sh 'trivy image --exit-code 1 --severity HIGH myapp:latest'
            }
        }
        stage('E2E Tests') {
            steps { sh 'mvn verify -Pintegration-tests' }
        }
    }
}

Test Pyramid Strategy

Follow the test pyramid: many fast unit tests at the base, fewer integration tests in the middle, minimal slow E2E tests at the top. This keeps your pipeline fast while maintaining confidence. Aim for 70% unit / 20% integration / 10% E2E.

Docker Hub & Dockerfile

Build images, push to Docker Hub, and write production-grade Dockerfiles

Docker Hub Workflow

Write
Dockerfile

→

docker build
local image

→

docker tag
name:version

→

docker push
to Hub

→

docker pull
anywhere

Docker Hub Commands

# Login to Docker Hub
docker login -u <username>

# Build image with tag
docker build -t <username>/myapp:1.0 .

# Tag an existing image
docker tag myapp:latest <username>/myapp:1.0

# Push to Docker Hub
docker push <username>/myapp:1.0

# Pull from Docker Hub (any machine)
docker pull <username>/myapp:1.0

# List local images
docker images

# Remove image
docker rmi <username>/myapp:1.0

Production-Grade Dockerfile (Multi-Stage)

# Stage 1: Build
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
RUN mvn dependency:go-offline   # cache deps layer
COPY src ./src
RUN mvn clean package -DskipTests

# Stage 2: Runtime (tiny image)
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /build/target/myapp.jar app.jar

# Security: run as non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

EXPOSE 8080
HEALTHCHECK --interval=30s CMD wget -qO- http://localhost:8080/health || exit 1
ENTRYPOINT ["java", "-jar", "app.jar"]

Dockerfile Best Practices

Use Multi-Stage Builds

Separate build tools from runtime. Final image contains only what's needed — 10x smaller.

Non-Root User

Never run containers as root. Create a dedicated user for security.

Layer Caching

Copy dependency files (pom.xml, package.json) before source code so deps are cached.

Use .dockerignore

Exclude node_modules, .git, target/ from build context to speed up builds.

DevOps Complete Learning Platform — 29 topics with diagrams, code, and examples

DevOps Mastery

What is DevOps?

The Core Idea

The DevOps Infinity Loop

Key Principles

🤝 Collaboration

⚡ Automation

📊 Continuous Feedback

🔄 Continuous Improvement

Popular DevOps Tools

DevOps vs SDLC

Side-by-Side Comparison

Key Insight

SDLC Phases (Traditional)

DevOps Enhances Each Phase

Plan → Jira / GitHub Issues

Code → Git, GitHub, GitLab

Test → Jenkins, Selenium

Deploy → Docker, Kubernetes

DevOps Life Cycle

The 8 Phases

1. 📋 Plan

2. 💻 Code

3. 🔨 Build

4. 🧪 Test

5. 📦 Release

6. 🚀 Deploy

7. ⚙️ Operate

8. 📊 Monitor

Why "Continuous"?

Real Example: Feature Shipping Timeline

Version Control & Basic Git Commands

What is Version Control?

Essential Git Commands

Git Branching Strategy (GitFlow)

Merge Conflicts

SDLC & DevOps — In Which Scenario?

When to Use Which?

DevOps in Real Scenarios

🛒 Amazon

🎬 Netflix

🚀 Facebook

🏦 Banks

What is CI/CD?

Three Concepts

CI — Continuous Integration

CD — Continuous Delivery

CD — Continuous Deployment

CI/CD Pipeline Stages

Jenkinsfile — Pipeline as Code

Poll SCM in Jenkins

What is Poll SCM?

Poll SCM vs Webhooks

Cron Syntax Explained

Second Phase of SDLC

What is the Second Phase?

Activities in This Phase

Feasibility Study

Requirement Gathering

SRS Document

Use Case Diagrams

Functional vs Non-Functional Requirements

What is TDD?

The TDD Cycle: Red → Green → Refactor

TDD Example in Python

Benefits of TDD

Better Design

Safety Net

Documentation

Confidence

4th Stage of Scrum

Scrum Framework Overview

The 4th Stage: Sprint Review

Who attends?

Duration

What happens?

Output

Scrum Roles

Kubernetes Architecture