DevOps: Git, Docker, Kubernetes and CI/CD

Why DevOps exists, what it really means (culture, practices and tools together), the software development life cycle from waterfall to Scrum and Kanban, the core DevOps practices with the DORA metrics that measure them, and the map of tools used at each stage. After this module you can explain DevOps in an interview without buzzwords, measure a team with the four DORA keys, and sketch a toolchain for a real release process.

1. What DevOps is and the problem it solvesDevOps is a way of working where the people who build software (development) and the people who run it (operations) share one goal: delivering changes to users quickly and safely. It is a culture plus a set of practices plus the tools that support them, not just a job title or a tool. The CALMS model and the infinity loop (plan, code, build, test, release, deploy, operate, monitor) describe it.25 min
2. The SDLC: waterfall, agile, Scrum and KanbanThe software development life cycle (SDLC) is the set of phases every piece of software goes through: requirements, design, build, test, release, and operate and maintain. Waterfall does these phases once, in order; agile repeats them in short cycles. Scrum and Kanban are two popular agile methods, and DevOps extends agile all the way to release and operations.30 min
3. Core DevOps practices and the DORA metricsDevOps rests on a few core practices: keep everything in version control, integrate and test continuously, deliver in small batches, define infrastructure as code, and monitor what runs. The DORA research programme measures how well a team delivers with four key metrics: deployment frequency, lead time for changes, change failure rate and time to restore service.35 min
4. The DevOps toolchain and your learning roadmapA toolchain is the set of tools a team uses at each stage of the DevOps loop: Jira to plan, Git to store code, GitHub Actions or Jenkins to build and test, Docker and Kubernetes to package and run, Terraform and Ansible to manage infrastructure, and Prometheus and Grafana to monitor. Learn one good tool per stage first, understand what problem it solves, and avoid collecting tools for their own sake.25 min

The Linux skills every DevOps engineer uses daily: moving around the filesystem, users and permissions, processes and systemd services, bash scripting with pipes, text tools and cron, and the networking commands that answer "why can my app not connect?". After this module you can work confidently on a Linux server, write a safe automation script, run an app as a service and troubleshoot common network problems.

1. The Linux filesystem and everyday commandsLinux runs most servers, almost all containers and most CI runners, so DevOps work happens in a Linux terminal. Everything lives in one tree that starts at / (root), with standard places like /etc for settings and /var/log for logs. A small set of commands (pwd, ls, cd, mkdir, cp, mv, rm, cat, less, tail, find) and a package manager (apt or dnf) cover most daily work.30 min
2. Users, groups and permissionsEvery file in Linux has an owner, a group, and read, write and execute permissions for the owner, the group and everyone else. Permissions are written as letters (rwxr-xr-x) or as octal numbers (755). DevOps engineers use chmod, chown, sudo and groups daily, and follow least privilege: give each user and service only the access it needs.30 min
3. Processes, signals and systemd servicesA process is a running program with an ID called the PID. You list processes with ps and top, stop them with kill (SIGTERM first, SIGKILL only if needed), and read exit codes where 0 means success. Long-running apps should be systemd services, managed with systemctl and read with journalctl, and you check server health with free, df, du and uptime.30 min
4. Bash scripting, text tools and cronA bash script is a text file of commands that runs from top to bottom, so a task you do by hand can run the same way every time. You use variables, quoting, if, loops, functions and arguments, start every script with set -euo pipefail, and join small tools like grep, awk, sed, sort and uniq with pipes. cron runs scripts on a schedule such as "30 2 * * *".35 min
5. Linux networking for DevOpsMost production problems sound like "the app cannot connect". A handful of commands answer them: ip addr and ip route show your addresses and routes, ping and curl test reachability, ss -tulpn shows which ports are listening, dig checks DNS, and ufw or firewalld control the firewall. ssh, scp, an ssh config file and port forwarding let you reach servers safely.30 min

Git is the tool every DevOps pipeline starts from: each build, test and deploy is triggered by a commit. This module goes from the three areas of a repository to branching, merging and conflicts, rebasing and undoing mistakes safely, working with remotes and pull requests in a team, and versioning releases with semantic versioning and tags. After this module you can keep a clean history, recover lost work, collaborate through pull requests and tag releases with the right version number.

1. Git basics: repositories, staging and commitsGit records snapshots of your project, called commits, so you can see who changed what, when and why, and go back at any time. Every change moves through three areas: the working directory (your files), the staging area (what goes into the next commit) and the repository (the saved history). A handful of commands, add, commit, status, log and diff, cover most of your daily work.30 min
2. Branching, merging and conflictsA branch is a movable label that points at a commit, so creating one is instant and cheap. You do each piece of work on its own branch and merge it back when it is ready. If the target branch has not moved, Git simply moves the label forward (a fast-forward); otherwise it creates a merge commit. When both sides changed the same lines, you get a conflict and decide the result yourself.30 min
3. Rebase, undo and rescue: rebase, reset, revert, reflog and stashRebase replays your commits on top of another branch to give a straight-line history, and interactive rebase lets you squash, reword or drop commits before sharing them. Never rebase commits others already have. To undo, use revert on shared history and reset only on local history. Lost a commit? git reflog remembers where HEAD has been. git stash parks unfinished work.35 min
4. Collaboration: remotes, pull requests and branching strategiesA remote is another copy of the repository, usually on GitHub or GitLab, named origin by default. You fetch to download others' work, pull to download and merge it, and push to upload yours. Teams change main through pull requests, which get reviewed and must pass checks. A branching strategy, such as GitHub flow or trunk-based development, and a shared commit style like Conventional Commits keep everyone in step.30 min
5. Semantic versioning, tags and releasesSemantic versioning gives every release a number MAJOR.MINOR.PATCH that tells users what changed: PATCH for bug fixes, MINOR for new features that do not break anything, MAJOR for breaking changes. Pre-releases like 2.0.0-rc.1 come before the final release. In Git you mark a release with a tag, and from Conventional Commits a tool can work out the next version and the changelog.30 min

Containers package an application with everything it needs, so it runs the same on a laptop, a CI runner and a production server. This module explains what containers are and how they differ from virtual machines, how to write efficient Dockerfiles with layer caching and multi-stage builds, how to run containers with ports, volumes, networks and limits, how to describe a whole app with Docker Compose, and how to keep images and containers secure. After this module you can build a small, safe image for your own service, run it with persistent data, and start a multi-container app with one command.

1. Containers, images and registriesA container is an isolated process that carries its own files, libraries and settings, so the app behaves the same everywhere. Unlike a virtual machine, it shares the host's kernel, which makes it start in a second and use little memory. You build containers from images, which are stacks of read-only layers, and you store and share images in registries such as Docker Hub or GHCR.30 min
2. Writing Dockerfiles: caching, multi-stage builds and small imagesA Dockerfile is the recipe for an image: a base image, then steps that copy files and run commands. Docker caches each step, so ordering matters: copy dependency files and install them before copying the rest of your code. Multi-stage builds compile in one stage and copy only the result into a small final image. Run as a non-root USER, use exec-form CMD, and keep secrets out.35 min
3. Running containers: ports, volumes, networks and limitsdocker run starts a container; options publish ports (-p host:container), set environment variables (-e), name it and run it in the background (-d). Container files vanish when the container is removed, so data goes in volumes or bind mounts. Containers on a user-defined network find each other by name. Restart policies and memory and CPU limits keep containers healthy on a shared server.35 min
4. Docker Compose: multi-container appsReal apps need several containers: a web app, a database, a cache. Docker Compose describes them all in one compose.yaml file, with their images, ports, environment, volumes, health checks and start order, and starts everything with docker compose up -d. Compose creates a shared network, so services reach each other by name. Be careful: docker compose down -v also deletes your volumes.35 min
5. Image and container securityA container is only as safe as its image and the way you run it. Use small, pinned base images, run as a non-root user, keep the file system read-only and drop Linux capabilities you do not need. Never bake secrets into images: use build secrets and runtime secrets. Scan images for known vulnerabilities, rebuild them often, avoid --privileged and the Docker socket, and sign what you publish.30 min

Run containers on a cluster with Kubernetes: how the control plane and nodes work together, Pods and Deployments with rolling updates, Services and Ingress for traffic, ConfigMaps, Secrets, resource limits and health probes, and Helm charts for packaging. After this module you can read and write the everyday Kubernetes YAML, deploy and update an app with kubectl, debug a failing pod, and install an app with Helm.

1. Why Kubernetes, and how a cluster worksKubernetes is an orchestrator: it runs many containers across many machines, restarts them when they fail, scales them and updates them without downtime. A cluster has a control plane (the brain: API server, etcd, scheduler, controllers) and worker nodes (kubelet, kube-proxy and a container runtime). You describe the state you want in YAML, and controllers keep working until the cluster matches it.30 min
2. Pods, ReplicaSets and DeploymentsA Pod is the smallest thing Kubernetes runs: one or more containers that share an IP address and storage. Pods are temporary, so you run them through a Deployment, which keeps the right number of copies alive using a ReplicaSet. A Deployment updates your app gradually with a rolling update, and kubectl rollout lets you watch, inspect and undo it.35 min
3. Services, Ingress and the Gateway APIPods come and go and their IP addresses change, so a Service gives a group of pods one stable name and IP and spreads traffic across them. Service types decide who can reach it: ClusterIP inside the cluster, NodePort on every node, LoadBalancer through a cloud load balancer. Ingress, and its newer successor the Gateway API, route outside HTTP traffic to Services by host name and path.30 min
4. Namespaces, ConfigMaps, Secrets, resources and probesNamespaces divide one cluster between teams and apps. ConfigMaps hold settings and Secrets hold passwords and keys, passed to pods as environment variables or files; Secrets are only base64-encoded by default, so protect them with RBAC, encryption at rest or an external secret manager. Requests and limits tell Kubernetes how much CPU and memory a container needs, and probes tell it whether a container is alive and ready for traffic.35 min
5. Helm and KustomizeHelm is the package manager for Kubernetes. A chart is a package of YAML templates plus default values; installing a chart creates a release, and every upgrade or rollback adds a numbered revision. You change a chart's settings with values files (-f) and --set, without editing the templates. Kustomize, built into kubectl, is the template-free alternative using a base plus overlays.30 min

Automate the path from a git push to production: continuous integration, delivery and deployment, pipeline stages, GitHub Actions workflows, Jenkins pipelines, testing and quality gates, versioned artefacts, and safe deployment strategies such as blue-green, canary and feature flags. After this module you can design a CI/CD pipeline, write a GitHub Actions workflow and a Jenkinsfile, set quality gates, and choose a deployment strategy with a rollback plan.

1. Continuous integration, delivery and deploymentContinuous integration (CI) means everyone merges small changes into the main branch often, and every push is built and tested automatically. Continuous delivery keeps every passing change ready to release with one approval; continuous deployment releases it to production automatically. A pipeline is the series of automated stages, from checkout and tests to building an artefact and deploying it.25 min
2. GitHub ActionsGitHub Actions runs CI/CD workflows defined in YAML files under .github/workflows/. A workflow starts on an event such as a push, a pull request, a manual button or a schedule, and runs jobs on runners; each job is a list of steps that either run shell commands or use ready-made actions. Matrix builds, caching, artefacts, environments with approvals, least-privilege tokens and OIDC make it fast and safe.35 min
3. Jenkins pipelinesJenkins is a free, self-hosted automation server that many companies, especially banks and large enterprises, still use for CI/CD. A controller schedules work and agents run the builds; a Jenkinsfile in the repository describes a declarative pipeline with stages, steps and post actions. Jenkins is very flexible thanks to its plugins, but you must run, update and secure it yourself.30 min
4. Testing, quality gates and artefactsA pipeline is only as good as its tests. The test pyramid says: many fast unit tests, fewer integration tests, and a few end-to-end tests, plus linting and static analysis. A quality gate blocks a build that fails tests, drops coverage or has critical vulnerabilities. What passes becomes an artefact: a versioned, unchangeable build output stored in a registry and tagged with the git SHA and a semantic version.30 min
5. Deployment strategies, feature flags and GitOpsHow you release matters as much as what you release. Recreate and rolling updates are simple; blue-green switches all traffic at once between two environments; canary sends a small share of users to the new version first and promotes it only if its metrics look healthy. Feature flags separate deploying code from releasing a feature, database changes use expand and contract, and GitOps lets an agent in the cluster pull the desired state from Git.35 min

Infrastructure as code means describing servers, networks, buckets and databases in text files that live in Git, so you can review them, repeat them and rebuild them. This module explains why teams moved away from clicking in cloud consoles, then teaches Terraform from zero: HCL syntax, providers, resources, variables and outputs, the init-plan-apply workflow, state and remote backends, drift, modules, environments and Terraform in CI. It also covers OpenTofu, the open-source fork. After this module you can write a small Terraform configuration, read a plan before applying it, keep state safe, and organise code into modules for dev, staging and production.

1. Why infrastructure as codeInfrastructure as code (IaC) means you write your servers, networks and databases as text files instead of clicking in a web console. The files live in Git, so changes are reviewed, repeatable and easy to rebuild after a disaster. Most IaC tools are declarative: you describe the end result and the tool works out the steps. Running the same code twice should change nothing the second time (idempotency).25 min
2. Terraform basics: HCL, providers, resources and the workflowTerraform reads .tf files written in HCL and talks to cloud APIs through plugins called providers. You declare resources (things to create), data sources (things to look up), variables (inputs), outputs (results) and locals (named values). The workflow is init, fmt, validate, plan and apply. Always read the plan: + means create, ~ means update in place, -/+ means replace, and - means destroy.35 min
3. Terraform state, backends and driftTerraform keeps a state file that maps each resource in your code to the real object in the cloud. State can contain secrets in plain text, so it never goes into Git; teams store it in a remote backend such as S3, Azure Storage, Google Cloud Storage or HCP Terraform, with locking so two people cannot apply at once. Drift is when reality changes outside Terraform; plan -refresh-only shows it.30 min
4. Modules, environments and Terraform in CIA module is a folder of Terraform files you can reuse with different inputs, like a function. You call child modules from your root module, from a local path or from the Terraform Registry with a pinned version. Teams keep separate state per environment, tag every resource, commit .terraform.lock.hcl, and run fmt, validate and plan in CI on every pull request, with apply only after merge and approval. OpenTofu is the open-source fork of Terraform.35 min

YAML is the file format behind Kubernetes manifests, Docker Compose, GitHub Actions and Ansible, so this module starts by teaching it properly, including the traps that break real deployments. Then it teaches Ansible: an agentless tool that connects to servers over SSH and brings them to a desired state. You will write inventories, run ad-hoc commands, write playbooks with variables, handlers, conditionals and loops, and organise them into roles with templates and encrypted secrets. After this module you can read and write YAML without surprises, and use Ansible to set up and keep a fleet of Linux servers in a known, repeatable state.

1. YAML in depthYAML is a text format for configuration that uses indentation instead of brackets. It has three building blocks: scalars (single values), maps (key: value pairs) and lists (lines starting with "- "). Indentation must use spaces, never tabs. Most YAML bugs come from bad indentation, unquoted special values like NO or 1.10, and colons or # inside plain text.30 min
2. Ansible: inventory and ad-hoc commandsConfiguration management keeps many servers in a known, desired state: the right packages, files, users and services. Ansible does this without installing an agent: a control node connects to managed nodes over SSH, pushes small programs called modules, and runs them. The inventory lists your servers in groups. Modules are idempotent, so a second run reports "ok" instead of "changed".30 min
3. Ansible playbooksA playbook is a YAML file with one or more plays. Each play picks hosts and runs a list of tasks, and each task calls one module. Variables can live in the play, in group_vars and host_vars, or come from facts that Ansible gathers about each server. Handlers run once at the end, only when a task that notified them changed something. when adds conditions, loop repeats a task, and --check --diff shows changes without making them.35 min
4. Roles, templates, Galaxy and VaultA role packs tasks, handlers, templates, files and variables into a standard folder layout, so you can reuse them across playbooks and projects. Templates use Jinja2: {{ variable }}, plus for loops and if blocks. Ansible Galaxy shares roles and collections. Ansible Vault encrypts secrets so they can live in Git safely. Terraform creates the servers; Ansible configures them.30 min

How a team sees what its software is doing in production: metrics, logs and traces, the golden signals, percentiles, Prometheus and Grafana, structured and centralised logging, and alerts that wake people only for real problems. After this module you can design a service dashboard, read and write basic PromQL and alert rules, set up safe structured logs, and write alerts with runbooks that an on-call engineer can act on.

1. Monitoring and observability: metrics, logs and tracesMonitoring means collecting numbers and events from running systems and checking them against what you expect. Observability is how well you can work out what is happening inside a system from what it outputs, even for questions you did not plan for. The three main kinds of data are metrics, logs and traces, and good teams watch user-facing signals like latency, traffic, errors and saturation, using percentiles instead of averages.30 min
2. Prometheus and GrafanaPrometheus is an open-source monitoring system that pulls (scrapes) metrics over HTTP from a /metrics page on each target and stores them as time series. You query them with PromQL, for example rate(http_requests_total[5m]), and write alert rules that Alertmanager routes to people. Grafana draws dashboards from Prometheus and many other data sources.35 min
3. Logging: structured, safe and centralisedLogs are time-stamped records of events that tell you exactly what happened. Write them as structured JSON with a timestamp, level, message and a request or trace ID, use log levels correctly, and never log secrets or personal data such as passwords, card numbers or Aadhaar numbers. Send logs from every server to one central place (Elastic Stack, EFK, Grafana Loki or a cloud log service) and control how long you keep them.30 min
4. Alerting and on-callAn alert should wake a person only when users are hurting, the person can do something about it, and it cannot wait until morning. Everything else becomes a ticket or a dashboard. Alertmanager and paging tools group, route and escalate alerts, and every alert needs a runbook that says what it means and what to check first. Too many noisy alerts cause alert fatigue, and then real problems are missed.30 min

Site Reliability Engineering (SRE) is Google's approach to running services: treat operations as a software problem, agree on how reliable a service must be, and use data to balance speed and stability. This module covers SLIs, SLOs, SLAs and error budgets, how to run an incident, blameless postmortems and toil, and the design patterns that keep systems up when parts fail. After this module you can set SLOs and compute error budgets, lead or join an incident calmly, write a useful postmortem, and add timeouts, retries, circuit breakers and other resilience patterns to a service.

1. SLIs, SLOs, SLAs and error budgetsAn SLI is a measured number about your service, usually good events divided by all events. An SLO is the target for that SLI over a time window, such as 99.9% of requests succeeding over 30 days. An SLA is a contract with customers that has penalties, so it is set looser than the SLO. The gap between 100% and the SLO is the error budget: the amount of failure you can afford, which you spend on releases and experiments.35 min
2. Incident managementAn incident is an unplanned problem that hurts users or puts them at risk and needs a coordinated response. Teams rate incidents by severity, give people clear roles (incident commander, communications lead, people fixing things, a scribe), and follow a lifecycle: detect, triage, mitigate, resolve, review. The rule that matters most: stop the damage first, then find the root cause.30 min
3. Blameless postmortems and toilA postmortem is a written review of an incident: what happened, the impact, the timeline, the causes, and action items with owners and dates. It must be blameless: it looks at how the system allowed the failure, not at who to punish, because blame makes people hide the truth. SRE teams also measure toil, the manual, repetitive work that can be automated, and aim to keep it under half of their time.30 min
4. Resilience patterns, capacity and chaos engineeringParts of a system will fail, so design for it. Put a timeout on every network call, retry only safe requests with exponential backoff and jitter, and use circuit breakers, bulkheads, rate limits and load shedding so one failing part cannot take down everything. Idempotency keys make retried payments safe. Plan capacity for known peaks, and use chaos engineering to test your defences on purpose, starting small.35 min

Build security into every stage of delivery instead of checking it at the end: threat modelling with STRIDE, the OWASP Top 10, pipeline security gates, secrets management, software supply chain security (scanning, SBOMs, signing) and Kubernetes security (RBAC, NetworkPolicies, Pod Security Standards). After this module you can design a pipeline that catches security problems early without blocking every release, keep secrets out of Git, and lock down a Kubernetes namespace.

1. DevSecOps: shifting security leftDevSecOps means building security into every step of delivery, from design to production, instead of a security check just before release. Finding a problem early (shifting left) is far cheaper than finding it in production. Threat modelling, the OWASP Top 10, secure defaults and sensible pipeline gates are the basic tools.30 min
2. Secrets managementA secret is anything that gives access: passwords, API keys, tokens and private keys. Secrets leak through Git history, logs, images, CI output and screenshots. Stop leaks with pre-commit scanning and push protection, store secrets in a vault or a cloud secret manager, prefer short-lived credentials such as OIDC from CI, and after a leak, revoke first.30 min
3. Software supply chain securityYour software is mostly other people's code: libraries, base images, build tools and CI actions. Supply chain security means knowing what is inside (SCA and SBOMs), scanning code, images and infrastructure files, checking where an artefact came from (signing and provenance), and pinning versions so nothing changes under you.35 min
4. Kubernetes securitySecuring Kubernetes means limiting who can do what (RBAC and ServiceAccounts), which pods can talk to which (NetworkPolicies), and what a container may do on its node (Pod Security Standards and securityContext). Add admission policies for images, protect Secrets, keep the cluster patched and watch the audit logs.35 min

Pull everything together: run deployments the GitOps way with Argo CD or Flux, see how platform teams build golden paths for other developers, build one end-to-end capstone project, choose and prepare for certifications such as CKA, CKAD and Terraform Associate, and get ready for DevOps interviews in India. After this module you can show a working pipeline from commit to monitored production, plan your certifications, and answer common DevOps interview questions with confidence.

1. GitOps and platform engineeringGitOps keeps the desired state of your systems in Git and lets an agent in the cluster, such as Argo CD or Flux, pull it and keep the cluster matching it. Changes and rollbacks become pull requests and git reverts. Platform engineering builds an internal developer platform with golden paths, so every team can ship safely without reinventing pipelines.30 min
2. Capstone project: from commit to monitored productionBuild one small project end to end: a college canteen order API in a protected Git repository, packaged with a multi-stage non-root Dockerfile, tested, scanned and pushed by GitHub Actions, deployed to Kubernetes on infrastructure made with Terraform, synced by Argo CD, and watched by Prometheus and Grafana with one SLO and an alert. A runbook and a clear README finish it. This one project is your strongest interview story.35 min
3. DevOps certifications: which, when and howCertifications do not replace projects, but they help you pass CV filters and give your study a deadline. The Kubernetes exams (CKA, CKAD, CKS) are hands-on tasks in a real terminal; KCNA, Terraform Associate and the cloud DevOps exams are question-based. Take them in a sensible order, practise with a simulator and imperative kubectl commands, and always check the current exam page, because details change.25 min
4. DevOps careers and interviews in IndiaDevOps work comes under many job titles: DevOps engineer, build and release engineer, cloud engineer, platform engineer, SRE and DevSecOps engineer. Freshers and juniors in India typically earn ₹4–8 LPA, rising to about ₹8–18 LPA with 2 to 5 years of experience, varying a lot by city, company and skills. A real GitHub portfolio, honest CV lines and practised answers to common questions get you hired; fake experience does not.35 min