DevOps is a culture and set of practices that combines software development (Dev) and IT operations (Ops) so that teams can build, test, and release software faster and more reliably. Instead of developers writing code and "throwing it over the wall" to an operations team, one team owns the whole cycle: writing, shipping, and running the software. The core ideas are automation of everything repeatable, small frequent releases instead of big risky ones, and fast feedback from production back to development.

The DevOps Lifecycle -

DevOps is usually drawn as an infinite loop: Plan → Code → Build → Test → Release → Deploy → Operate → Monitor, and back to Plan. Each stage feeds the next, and monitoring feeds what to plan next.

• Building : Turning source code into a runnable artifact (a bundle, binary, or container image).
• Testing : Automatically verifying that changes work and nothing existing broke.
• Tooling : The chain of tools that automates each stage, from version control to monitoring.
• Deployment : Getting the built and tested artifact running in production safely.

• DevSecOps : Extends DevOps by adding security checks (dependency scanning, secret detection, code analysis) into the same automated pipeline instead of leaving security for the end.
• SRE : Site Reliability Engineering is a related discipline that applies software engineering to operations, using SLOs and error budgets to balance reliability against release speed.

Version control records every change to the codebase, who made it, and why, so teams can work on the same code in parallel, review changes, and roll back mistakes. It is the foundation of DevOps: every automation pipeline starts from a change pushed to version control.

• Git : The standard distributed version control system. Every developer has a full copy of the repository, and work happens on branches that are merged after review. (See the Git cheatsheet for commands.)
• Hosting Platforms : GitHub, GitLab, and Bitbucket host repositories and add pull/merge requests, code review, issue tracking, and built-in CI/CD.
• Pull Request (PR) : A proposal to merge a branch, where teammates review the changes and automated checks run before the merge is allowed.

Common Workflows -

• Feature Branch Workflow : Every feature or fix gets its own branch off the main branch and is merged back through a pull request. The most common workflow.
• Trunk-Based Development : Everyone merges small changes into the main branch frequently, often daily, with unfinished work hidden behind feature flags. Pairs best with CI/CD.
• GitFlow : A heavier model with long-lived develop and main branches plus release and hotfix branches. Suits products with scheduled, versioned releases.

A build system turns source code into something runnable: it resolves dependencies, compiles or transpiles code, runs tools like linters, and produces an artifact (a bundle, binary, package, or container image). Builds must be repeatable, so the same input always produces the same output on any machine.

• Package Managers : Install and lock project dependencies: npm/pnpm/yarn (JavaScript), pip/poetry (Python), Maven/Gradle (Java), Cargo (Rust). Lock files pin exact versions so every build uses the same dependencies.
• Bundlers : Combine many source files and dependencies into optimized files for the browser, with minification, tree shaking (dropping unused code), and code splitting.
• Compilers / Transpilers : Convert code from one form to another, such as TypeScript to JavaScript (tsc), modern JS to older JS (Babel), or source to binary (Go, Rust).
• Task Runners / Build Tools : Orchestrate build steps: Make, Gradle, and the scripts section of package.json.

Webpack vs Vite -

• Webpack : The long-standing standard bundler. Extremely configurable through loaders and plugins, but configuration is complex and dev rebuilds get slow on large projects.
• Vite : The modern default. Serves source files natively over ES modules in development (near-instant startup and hot reload) and bundles with Rollup for production. Minimal configuration.
• Others: esbuild and SWC (very fast, used inside other tools), Rollup (libraries), Turbopack (Next.js).

Automated testing means code that verifies other code, running the same checks on every change without human effort. In DevOps, tests are the safety net that makes frequent releases possible: if the tests pass, the change is considered safe to ship.

The Test Pyramid -

• Unit Tests : Test one function or class in isolation. Fast and cheap, so you write many. Tools: Jest, Vitest (JavaScript), pytest (Python), JUnit (Java).
• Integration Tests : Test that components work together, such as an API endpoint talking to a real database. Slower, so fewer.
• End-to-End (E2E) Tests : Drive the real application like a user (open browser, click, type, assert). Slowest and most fragile, so fewest. Tools: Playwright, Cypress, Selenium.

• Static Analysis : Linters (ESLint) and type checkers (TypeScript) catch errors without running the code, usually as the first pipeline step.
• Code Coverage : Measures how much of the code the tests execute. Useful as a signal, but 100% coverage does not mean bug-free.
• Shift Left : The practice of testing as early as possible (on every commit) rather than at the end of a release cycle.

CI/CD automates the path from a code change to running software. It is implemented as a pipeline: an automated sequence of steps that runs every time code is pushed.

• Continuous Integration (CI) : Every push is automatically built and tested. Broken changes are caught in minutes, and the main branch stays releasable at all times.
• Continuous Delivery (CD) : Every change that passes CI is automatically prepared for release; deploying to production is one manual approval away.
• Continuous Deployment : Goes one step further; every passing change deploys to production automatically with no human step.

Pipeline Stages -

A typical pipeline: Push → Lint → Build → Test → Package → Deploy to staging → Deploy to production. If any stage fails, the pipeline stops and the team is notified. Pipelines are defined in code (usually YAML) and versioned with the project.

CI/CD Tools -

• GitHub Actions : CI/CD built into GitHub. Workflows are YAML files in .github/workflows/ triggered by events like push, pull request, or a schedule. A marketplace of reusable actions covers most tasks.
• Jenkins : The veteran self-hosted automation server. Highly flexible with a huge plugin ecosystem and pipelines defined in a Jenkinsfile, but you maintain the server yourself. Common in enterprises.
• Others : GitLab CI (built into GitLab), CircleCI, Azure DevOps Pipelines, and ArgoCD (GitOps-style deployment for Kubernetes, where the cluster syncs itself to what the repo declares).

Containerization packages an application together with its dependencies into a container: a lightweight, isolated unit that runs the same on any machine with a container runtime. Containers share the host OS kernel instead of carrying a full guest OS, so they start in seconds and use far fewer resources than virtual machines. They solve the classic "works on my machine" problem.

Docker :

Docker is the standard tool for building and running containers.

• Dockerfile : A text file of instructions that describes how to build an image: base image, files to copy, commands to run, and what to execute on start.
• Image : The built, immutable package (app + dependencies + runtime). Images are layered, so unchanged layers are reused between builds.
• Container : A running instance of an image. Many containers can run from the same image.
• Registry : Where images are stored and shared: Docker Hub, GitHub Container Registry, AWS ECR.
• Docker Compose : Defines multi-container setups (app + database + cache) in one docker-compose.yml file, started together with docker compose up.

Typical flow: docker build -t myapp . builds the image, docker run -p 3000:3000 myapp runs it, and docker push publishes it to a registry for servers to pull.

One container is easy; hundreds across many servers are not. An orchestrator manages containers at scale: it decides which machine runs each container, restarts crashed ones, scales the count up and down, rolls out new versions gradually, and routes traffic to healthy instances.

Kubernetes (K8s) :

Kubernetes is the industry-standard orchestrator, originally created by Google. You declare the desired state in YAML ("run 3 replicas of this image") and Kubernetes continuously works to make reality match it, which is what enables self-healing.

• Cluster : The whole system: a control plane that makes decisions plus worker nodes (machines) that run the workloads.
• Pod : The smallest deployable unit, usually one container. Pods are disposable; they are replaced, not repaired.
• Deployment : Declares how many replicas of a pod should run and manages rolling updates and rollbacks.
• Service : A stable network address that load balances traffic across a set of pods, since individual pods come and go.
• Ingress : Routes external HTTP traffic into the cluster based on host or path.
• ConfigMap & Secret : Inject configuration and sensitive values into pods without baking them into the image.

• Managed Kubernetes : Cloud providers run the control plane for you: AWS EKS, Google GKE, Azure AKS.
• Alternatives : Docker Swarm (simpler, less used), HashiCorp Nomad, or managed container services like AWS ECS and Google Cloud Run when full Kubernetes is overkill.
• Helm : The package manager for Kubernetes; installs and upgrades whole applications as versioned charts.

A deployment strategy defines how a new version replaces the old one in production while minimizing downtime and risk.

• Rolling Deployment : Instances are updated a few at a time until all run the new version. No downtime and no extra infrastructure, but two versions run side by side during the rollout. The Kubernetes default.
• Blue-Green Deployment : Two identical environments: blue (live) and green (new version). Traffic switches to green in one step, and switching back is an instant rollback. Costs double the infrastructure during the deploy.
• Canary Deployment : The new version first receives a small slice of traffic (say 5%). If metrics stay healthy, traffic shifts gradually to 100%; if not, the canary is rolled back and only a few users were affected.
• Feature Flags : Deploy code with new features switched off, then enable them per user, per region, or gradually, without redeploying. Separates deployment from release.
• Rollback : Every strategy needs a fast way back: redeploy the previous image, switch traffic back, or flip the flag off.

Deployment is not the end of the pipeline; you need to know how the software behaves in production. Observability is built on three pillars, and its output feeds the next development cycle, closing the DevOps loop.

• Metrics : Numeric time-series data such as request rate, error rate, latency, CPU, and memory. Collected by Prometheus, visualized in Grafana dashboards.
• Logs : Timestamped event records from applications and infrastructure, centralized and searchable with the ELK stack (Elasticsearch, Logstash, Kibana) or Grafana Loki.
• Traces : Follow a single request across services to find where time was spent or where it failed. Tools: Jaeger, OpenTelemetry.
• Alerting : Rules that page a human when something crosses a threshold, such as error rate above 1% for 5 minutes. Alert on symptoms users feel, not on every internal blip.
• Health Checks : Endpoints like /health that load balancers and orchestrators probe to decide whether an instance should receive traffic.