Sangam Mukherjee DevOps Beginner Blueprint

// When should you use the DevOps Beginner Blueprint?

Use this skill when onboarding yourself or a team member to DevOps from scratch, when setting up a new project's DevOps pipeline end-to-end, or when you need a sequenced checklist to implement Git, Docker, CI/CD, AWS, and Kubernetes on an existing codebase.

// What do you need before starting the DevOps Beginner Blueprint?

• Demo/Base Applicationrequired
  A real application (client side + server side) that will serve as the anchor for every concept applied. Mukherjee calls this the 'man application' or 'demo app'.
• Target Tech Stackrequired
  The front-end and back-end technologies in use (e.g. React + Node, or any equivalent). Specific stack does not change the DevOps steps.
• Cloud Provider Account
  An AWS account (or equivalent) for EC2 deployment steps.
• Operating Systemrequired
  Windows, Mac, or Linux. Determines WSL setup requirement.

// What core principles guide the DevOps Beginner Blueprint?

// How do you apply the DevOps Beginner Blueprint step by step?

1. 1

   Orient with the Seven-Pillar DevOps Life Cycle

   Map your project explicitly to all seven pillars: Plan, Develop, Build, Test, Release, Deploy, Monitor. Identify which pillars are currently manual, missing, or broken. This audit drives the rest of the workflow.

2. 2

   Prepare the Linux Environment

   On Windows, install WSL (Windows Subsystem for Linux) via PowerShell with 'wsl --install' to get an Ubuntu distribution. On Mac/Linux, confirm terminal access. Master the mandatory baseline commands before touching any DevOps tooling: pwd (current path), ls / ls -l / ls -a (list files), cd (navigate), touch (create file), mkdir (create directory), rm (delete file), rm -r (delete directory), find [path] -name [filename] (locate files), grep [string] [file] (search content inside file).

3. 3

   Write and Execute a Shell Script for Automation

   Follow the four-step shell scripting process: (1) Create the file using 'nano scriptname.sh'. (2) Write the script — always start with the shebang line '#!/bin/bash', then add commands, variables (NAME=value, echo $NAME), and conditionals (if [ $NUM -gt 5 ]; then … else … fi). (3) Make executable with 'chmod +x scriptname.sh'. (4) Run with './scriptname.sh'. Use shell scripts whenever you need to automate repeated command sequences — software installation, system configuration, backups, cron jobs.

4. 4

   Initialise Git in the Demo App Root

   Navigate to the root directory of the project (outside client and server folders so both are tracked together). Run 'git init'. Confirm a hidden .git folder appears — this is Git tracking changes locally. Never initialise inside a sub-folder if you need the whole project tracked.

5. 5

   Create and Configure the .gitignore File

   Create a .gitignore file at the project root before any staging. Add node_modules/ immediately. Also add: build/dist artefacts, environment variable files containing sensitive data, OS system files. Verify the tracked file count drops dramatically in your IDE after saving. Rule: anything you do not want public or that can be regenerated locally belongs in .gitignore.

6. 6

   Execute the Git Local Workflow (Add → Commit)

   Follow the three-zone model: Working Directory (local changes, tracked by Git but unstaged) → Staging Area (git add . to snapshot changes ready for commit) → Committed State (git commit -m 'descriptive message' to store a snapshot). Write commit messages that describe what changed and why (e.g. 'payment feature for PayPal added'), never vague messages. Check state at any point with 'git status'.

7. 7

   Connect Local Repository to GitHub and Push

   Create a repository on GitHub (the cloud-based hosting service). Link local to remote with 'git remote add origin [URL]'. Push with 'git push -u origin main'. Establish branching strategy: use separate branches for dev, stage, and prod environments — do not commit directly to main/prod. Understand the collaboration loop: team members push to the shared GitHub repo; others pull to get updated code locally.

8. 8

   Containerise the Demo App with Docker

   Learn Docker architecture: Docker Engine, Images, Containers. Write a Dockerfile for both the client side and the server side of the demo app. Build images and run first container locally. Use Docker Compose to orchestrate multi-container setups (front end + back end + database running together). Validate the app runs identically in a container as it does natively — this proves environment parity.

9. 9

   Implement Continuous Integration (CI) with GitHub Actions

   Set up a GitHub Actions workflow file (.github/workflows/). Define CI flow: on every push/PR, automatically trigger build and lint checks. Add pre-commit hooks (Prettier/linting) to enforce code quality before code even reaches GitHub. CI sits in the Build and Test pillars of the DevOps life cycle. Goal: no manual build steps — every push is automatically validated.

10. 10

    Deploy the Demo App to AWS EC2

    Create AWS account. Launch an EC2 instance. Install Docker and Docker Compose on the EC2 instance. Deploy the demo app containers on EC2. Access the running app via the instance's public IP. This step proves the app is environment-agnostic — the same Docker setup that ran locally now runs in the cloud.

11. 11

    Implement Continuous Deployment (CD) to Automate EC2 Updates

    Extend the GitHub Actions workflow to include a CD stage. Configure it so that every push to the main/prod branch automatically SSHs into the EC2 instance, pulls the latest image, and restarts the containers. After this step, no manual deployment is ever required — push code, it deploys itself. This completes the CI/CD pipeline within the Deploy pillar.

12. 12

    Deploy the Demo App on Kubernetes (Basics)

    Install kubectl and Minikube for a local Kubernetes cluster. Start the cluster and verify it. Build and load Docker images into Kubernetes. Create a Deployment manifest for the demo app. Create a Service manifest to expose the deployment. Understand the 'why Kubernetes' argument: Docker alone handles single-host container management; Kubernetes handles orchestration across multiple hosts, high availability, and scaling. Keep this step conceptual-heavy with practical basics — deep Kubernetes is a later-part topic.

// What does the DevOps Beginner Blueprint look like in practice?

// What mistakes should you avoid when applying this DevOps blueprint?

• Initialising 'git init' inside a sub-folder (e.g. inside /client only) instead of the project root — this means the server side is never tracked by Git.
• Forgetting to create .gitignore before the first 'git add .' — node_modules (thousands of files) gets staged and pushed, bloating the repository permanently.
• Writing vague commit messages like 'changes' or 'fix' — in a team context this makes the Git history unreadable and release tracking impossible.
• Skipping the staging area mental model — confusing 'git add' (staging) with 'git commit' (snapshotting) leads to partial or accidental commits.
• Going too conceptual in early sections without tying each concept back to the demo app — learners disengage because they cannot see where the theory lands in practice.
• Treating Kubernetes as a drop-in replacement for Docker Compose at the beginner stage — Kubernetes solves orchestration at scale; introducing it before Docker fundamentals are solid creates confusion.
• Deploying directly to prod without staging environments — violates the P0/P1 sensitivity mindset; always use dev → stage → (pre-prod) → prod release flow for any user-facing application.
• Pushing sensitive credentials (API keys, database passwords, .env files) to a public GitHub repository — these must be listed in .gitignore and managed via environment variables or secrets managers.
• Not making a shell script executable with 'chmod +x' before running it — the script will fail silently or throw a permission error.
• Skipping WSL setup on Windows and trying to run Linux-optimised DevOps tools natively — Docker, Kubernetes tooling, and shell scripts are optimised for Linux environments.

// What key DevOps terms do you need to know?

Man Application / Demo App

The single real project used as the anchor throughout the entire DevOps course. Every concept taught is immediately applied to this application so learning is always practical, never purely abstract.

Seven-Pillar DevOps Life Cycle

Mukherjee's ordered model of all DevOps activity: Plan → Develop → Build → Test → Release → Deploy → Monitor. Every tool and practice belongs explicitly in one of these seven stages.

P0 / P1 Application

Criticality classification for applications. P0/P1 are user-facing, revenue-critical applications (e.g. a live SaaS product) where downtime directly impacts business. Higher criticality demands tighter release flows, more staging environments, and stricter DevOps practices.

Staging Area

The Git zone between the Working Directory and a Commit. Files are moved here with 'git add' — it is where your snapshot is 'made ready' before being permanently recorded with 'git commit'.

G Ignore / .gitignore

A plain text file at the project root listing all files and directories Git should not track. Used to exclude node_modules, build artefacts, and sensitive data from version control.

Distributed Version Control System (DVCS)

What Git is. Every developer holds a full copy of the repository and its history locally — no dependency on a central server for day-to-day work.

WSL (Windows Subsystem for Linux)

A Windows feature that allows running a Linux distribution (e.g. Ubuntu) directly on a Windows machine. Required because DevOps tooling (Docker, Kubernetes, CI/CD tools) is optimised for Linux environments.

Shebang (#!/bin/bash)

The mandatory first line of any shell script. Tells the Linux OS which shell interpreter to use to execute the commands in the file.

Continuous Integration (CI)

The DevOps practice of automatically building and testing code every time a developer pushes changes, using tools like GitHub Actions. Eliminates manual build steps and catches errors early in the Build and Test pillars.

Continuous Deployment (CD)

The extension of CI that automatically deploys validated code changes to a target environment (e.g. EC2) without manual intervention. Lives in the Deploy pillar.

Docker Compose

A tool for defining and running multi-container Docker applications using a single configuration file. Used to orchestrate the client, server, and database containers of the demo app together in one command.

Minikube

A tool that runs a local, single-node Kubernetes cluster on a developer's machine. Used to learn and test Kubernetes concepts without needing a cloud-based cluster.

// FREQUENTLY ASKED QUESTIONS