From 74e7fb19393b95ee8e93fd8e1c27a16a185bb865 Mon Sep 17 00:00:00 2001 From: Ajay Dhangar Date: Mon, 30 Mar 2026 21:16:57 +0530 Subject: [PATCH] added new docs for devOps --- .../git-and-github/_category_.json | 8 ++ .../git-and-github/branching-strategies.mdx | 92 +++++++++++++ .../git-and-github/git-for-devops.mdx | 84 ++++++++++++ .../git-and-github/git-hooks-automation.mdx | 86 ++++++++++++ .../git-and-github/github-actions-intro.mdx | 125 ++++++++++++++++++ .../git-and-github/gitops-fundamentals.mdx | 93 +++++++++++++ 6 files changed, 488 insertions(+) create mode 100644 absolute-beginners/devops-beginner/git-and-github/_category_.json create mode 100644 absolute-beginners/devops-beginner/git-and-github/branching-strategies.mdx create mode 100644 absolute-beginners/devops-beginner/git-and-github/git-for-devops.mdx create mode 100644 absolute-beginners/devops-beginner/git-and-github/git-hooks-automation.mdx create mode 100644 absolute-beginners/devops-beginner/git-and-github/github-actions-intro.mdx create mode 100644 absolute-beginners/devops-beginner/git-and-github/gitops-fundamentals.mdx diff --git a/absolute-beginners/devops-beginner/git-and-github/_category_.json b/absolute-beginners/devops-beginner/git-and-github/_category_.json new file mode 100644 index 0000000..286a0e2 --- /dev/null +++ b/absolute-beginners/devops-beginner/git-and-github/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "Git & GitHub", + "position": 6, + "link": { + "type": "generated-index", + "description": "Go beyond simple commits. Learn how to use Git to automate deployments, protect your production environment, and manage infrastructure through code. Discover how to leverage GitHub's powerful features to collaborate effectively, automate workflows, and enhance your DevOps practices." + } +} \ No newline at end of file diff --git a/absolute-beginners/devops-beginner/git-and-github/branching-strategies.mdx b/absolute-beginners/devops-beginner/git-and-github/branching-strategies.mdx new file mode 100644 index 0000000..6f61a0c --- /dev/null +++ b/absolute-beginners/devops-beginner/git-and-github/branching-strategies.mdx @@ -0,0 +1,92 @@ +--- +sidebar_position: 2 +title: "Branching Strategies: Organizing the Chaos" +sidebar_label: "2. Branching Strategies" +description: "Compare GitFlow, Trunk-Based Development, and GitHub Flow to find the best fit for your DevOps pipeline." +--- + +A **Branching Strategy** is a set of rules that defines when and how code is moved from a developer's laptop to the production server. If everyone pushes directly to the `main` branch, the site will break every 5 minutes. + +We need a "Traffic System" to ensure only tested, high-quality code reaches our users. + +## 1. Trunk-Based Development (The High-Speed Choice) + +In **Trunk-Based Development**, all developers work on a single branch (the "Trunk" or `main`). They make small, frequent updates and merge them multiple times a day. + +```mermaid +gitGraph + commit id: "Initial" + commit id: "Build" + branch feature-1 + checkout feature-1 + commit id: "Fix-A" + checkout main + merge feature-1 + branch feature-2 + checkout feature-2 + commit id: "Fix-B" + checkout main + merge feature-2 + commit id: "Deploy-v1.1" +``` + +* **Best for:** Senior teams with **Strong Automated Testing**. +* **Why it's DevOps-friendly:** It prevents "Merge Hell" (where two people change the same file and can't fix it later) and allows for **Continuous Integration (CI)**. + +## 2. GitFlow (The Structured Choice) + +**GitFlow** is a more complex, "Industrial Level" strategy used by large teams. It uses specific branches for different purposes. + +| Branch Name | Purpose | +| :--- | :--- | +| `main` | **Production Ready.** Only contains stable, released code. | +| `develop` | **Integration.** Where features meet to be tested together. | +| `feature/*` | **New Work.** Where individual tasks are built (e.g., `feature/login-ui`). | +| `release/*` | **Polishing.** Final bug fixes before a big version launch. | +| `hotfix/*` | **Emergency.** Quick fixes for bugs currently live on the site. | + +### The Flow of Code: + +$$Feature \rightarrow Develop \rightarrow Release \rightarrow Main$$ + +* **Best for:** Large teams with **Complex Release Cycles**. +* **Why it's DevOps-friendly:** It provides a clear structure for managing different stages of development and allows for **Versioning** (e.g., v1.0, v1.1). + +## 3. GitHub Flow (The Modern Standard) + +This is the strategy we often use for **CodeHarborHub** open-source projects. It is simpler than GitFlow but safer than pure Trunk-based. + +1. **Create a Branch:** Give it a descriptive name (e.g., `update-readme`). +2. **Add Commits:** Save your work. +3. **Open a Pull Request (PR):** Ask for a "Peer Review" and let the CI tests run. +4. **Discuss & Review:** Other developers suggest changes. +5. **Merge & Deploy:** Once the green checkmark appears, merge to `main` and deploy. + +## Comparing the Strategies + +| Strategy | Speed | Risk | Complexity | Recommended For | +| :--- | :--- | :--- | :--- | :--- | +| **Trunk-Based** | Blazing Fast | High | Low | Startups / Daily Deploys | +| **GitHub Flow** | Balanced | Medium | Medium | Web Apps / SaaS | +| **GitFlow** | Slower | Very Low | High | Banks / Medical Software | + +## DevOps Best Practice: Protected Branches + +Regardless of the strategy you choose, a DevOps engineer **never** allows direct pushes to `main`. + +In GitHub, we use **Branch Protection Rules**: + +* **Require a Pull Request:** No one can merge without a review. +* **Require Status Checks:** The "Merge" button stays grey until the **Docker Build** and **Unit Tests** pass. +* **Require Signed Commits:** Ensures the code actually came from a verified team member. + +## Summary Checklist + +* [x] I can explain why pushing directly to `main` is dangerous. +* [x] I understand that **Trunk-Based** development requires great automated tests. +* [x] I know that **GitFlow** is best for complex, versioned releases. +* [x] I understand the 5-step process of **GitHub Flow**. + +:::info Note +If your team is small (2-3 people), start with **GitHub Flow**. It provides the perfect balance of speed and safety without the headache of managing 5 different branch types\! +::: \ No newline at end of file diff --git a/absolute-beginners/devops-beginner/git-and-github/git-for-devops.mdx b/absolute-beginners/devops-beginner/git-and-github/git-for-devops.mdx new file mode 100644 index 0000000..59614b4 --- /dev/null +++ b/absolute-beginners/devops-beginner/git-and-github/git-for-devops.mdx @@ -0,0 +1,84 @@ +--- +sidebar_position: 1 +title: "Git: The DevOps Backbone" +sidebar_label: "1. Git for DevOps" +description: "Learn why Git is the starting point for every automation pipeline and how it manages more than just source code." +--- + +In your early coding days, you used Git to keep track of your `index.js` or `style.css`. In DevOps, we use Git to manage **everything**: +* **Infrastructure:** Your AWS server settings (Terraform/CloudFormation). +* **Configuration:** Your environment variables and API keys (Encrypted). +* **Pipelines:** The scripts that build and deploy your app (GitHub Actions YAML). +* **Containers:** The blueprints for your environment (Dockerfiles). + +## 1. The "Control Tower" Analogy + +Think of a busy airport. +* The **Planes** are your application updates. +* The **Runway** is your Production Server. +* **Git is the Control Tower.** Nothing lands on the runway unless the Control Tower (Git) gives the green light. If a pilot (Developer) tries to land without permission, the system blocks them. If a plane crashes (A bug is deployed), the Control Tower can "Roll back" the runway to a safe state instantly. + +## 2. Git as an Automation Trigger + +In a manual world, you finish code and then manually upload it to a server. In a DevOps world, the moment you `git push`, a chain reaction starts. + +```mermaid +graph LR + A[💻 Developer Push] --> B{🐙 GitHub} + B --> C[🧪 Run Tests] + C --> D[🐳 Build Docker Image] + D --> E[🚀 Deploy to AWS/Azure] + + style B fill:#f96,stroke:#333,stroke-width:2px,color:#000 + style C fill:#9cf,stroke:#333,stroke-width:2px,color:#000 + style D fill:#fc9,stroke:#333,stroke-width:2px,color:#000 + style E fill:#c9f,stroke:#333,stroke-width:2px,color:#000 +``` + +### The "Git-Flow" Logic: + +We use specific events in Git to trigger different actions: + +1. **Push to `feature` branch:** Triggers Unit Tests. +2. **Pull Request to `main`:** Triggers Integration Tests and Peer Review. +3. **Merge to `main`:** Triggers the final Deployment to the live website. + +## 3. Audit Trails: The "Who, What, When" + +One of the biggest requirements in "Industrial Level" DevOps is **Accountability**. If the **CodeHarborHub** website goes down at 2:00 AM, we don't guess what happened. We check the Git Log. + +$$Change\_Log = \text{Author} + \text{Timestamp} + \text{Commit\_Hash} + \text{Diff}$$ + +Because every change to our infrastructure is committed to Git, we have a perfect "Time Machine." We can see exactly which line of code broke the server and revert it in seconds using: +`git revert ` + +## 4. Collaboration at Scale + +DevOps is about breaking down silos between Developers and Operations. Git is the "Meeting Room" where this happens. + +* **Developers** write the app code. +* **Operations** write the Dockerfiles and Kubernetes manifests. +* They both collaborate on the **same repository**, ensuring that the environment matches the code. + +## Essential DevOps Git Commands + +While you know `commit` and `push`, these are the "Power User" commands for DevOps: + +| Command | Why DevOps use it | +| :--- | :--- | +| `git diff` | To see exactly what configuration changed before deploying. | +| `git log --graph` | To visualize how different features are merging into production. | +| `git tag -a v1.0` | To mark a specific "Release" point in time for the servers. | +| `git stash` | To quickly clear the workspace when a production hotfix is needed. | +| `git cherry-pick` | To grab a specific bug fix from one branch and apply it to another. | + +## Summary Checklist + + * [x] I understand that Git manages **Infrastructure** as well as **Code**. + * [x] I know that a `git push` is often the trigger for a CI/CD pipeline. + * [x] I understand how Git provides an audit trail for troubleshooting. + * [x] I can explain why "Everything as Code" starts with Git. + +:::info The "GitOps" Secret +The ultimate goal of DevOps is **GitOps**. This means the state of your production server is *always* an exact reflection of what is in your Git repository. If you change a value in Git, the server changes itself automatically\! +::: \ No newline at end of file diff --git a/absolute-beginners/devops-beginner/git-and-github/git-hooks-automation.mdx b/absolute-beginners/devops-beginner/git-and-github/git-hooks-automation.mdx new file mode 100644 index 0000000..d19b2e9 --- /dev/null +++ b/absolute-beginners/devops-beginner/git-and-github/git-hooks-automation.mdx @@ -0,0 +1,86 @@ +--- +sidebar_position: 3 +title: "Git Hooks: The Automated Gatekeepers" +sidebar_label: "3. Git Hooks Automation" +description: "Learn how to use pre-commit and pre-push hooks to ensure only high-quality code leaves your machine." +--- + +Have you ever committed code only to realize 5 minutes later that you left a `console.log` or a syntax error in the file? **Git Hooks** prevent these "silly mistakes" by running checks locally on your computer. + +## 1. How Git Hooks Work + +Inside every Git repository, there is a hidden folder called `.git/hooks`. This folder contains "Template" scripts for every stage of the Git lifecycle. + +```mermaid +graph TD + A[Developer types: git commit] --> B{Pre-commit Hook} + B -- "Fail (Bugs found)" --> C[Commit Rejected] + B -- "Pass (Clean code)" --> D[Commit Successful] + D --> E[Pre-push Hook] + E -- "Tests Fail" --> F[Push Blocked] + E -- "Tests Pass" --> G[Code sent to GitHub] +``` + +### The "Gatekeeper" Logic: + +If a script in the `hooks` folder returns an **Error**, Git will stop the action immediately. For example, if your pre-commit hook runs a linter and finds a formatting issue, it will return a non-zero exit code, and Git will reject the commit. This forces you to fix the issue before it can be saved in your Git history. + +## 2. The Two Most Important Hooks + +As a DevOps engineer, you will focus on these two: + +### A. Pre-commit (The Linter) + +This runs the moment you type `git commit` but **before** the commit message is saved. + +* **Job:** Check for formatting (Prettier), syntax errors (ESLint), or "Secret Leaks" (like accidentally committing your AWS Password\!). +* **Benefit:** Your Git history stays clean and professional. + +### B. Pre-push (The Tester) + +This runs when you type `git push`. + +* **Job:** Run your **Unit Tests**. +* **Benefit:** Ensures that you never break the "Main" build on GitHub because you forgot to run tests locally. + +## The Mathematics of Prevention + +The cost of fixing a bug increases the further it travels from the developer's laptop. + +$$Cost\_of\_Fix = \text{Local} < \text{GitHub} < \text{Staging} < \text{Production}$$ + +By using Git Hooks, we catch errors at the **Local** stage, saving hours of debugging time and server costs. + +## 3. Professional Tooling: "Husky" + +Manually managing scripts in `.git/hooks` is difficult because that folder is not shared with your team. For **CodeHarborHub** projects, we use a tool called **Husky**. + +Husky makes it easy to share hooks across your whole team via your `package.json`. + +### How to set up Husky: + +1. **Install:** `npm install husky --save-dev` +2. **Initialize:** `npx husky install` +3. **Add a Hook:** + ```bash + npx husky add .husky/pre-commit "npm run lint" + ``` + +Now, every time a developer on your team tries to commit, Husky will automatically run the linter! + +## 4. Best Practices + +1. **Keep them Fast:** A pre-commit hook shouldn't take more than 5-10 seconds. If it's too slow, developers will get frustrated and skip it. +2. **Don't Over-automate:** Use pre-commit for "Small" things (Linting) and pre-push for "Big" things (Testing). +3. **Never Commit Secrets:** Use a hook like `gitleaks` to scan your code for passwords before they ever leave your machine. + +## Summary Checklist + +* [x] I know that Git Hooks live in the `.git/hooks` folder. +* [x] I understand that a "Non-zero" exit code stops the Git action. +* [x] I can explain the difference between **pre-commit** and **pre-push**. +* [x] I know how to use **Husky** to share hooks with my team. + +:::warning The "Skip" Button +You can skip hooks using `git commit --no-verify`. Use this **ONLY** in extreme emergencies. If you skip hooks, you are bypassing the safety net of your project\! +::: \ No newline at end of file diff --git a/absolute-beginners/devops-beginner/git-and-github/github-actions-intro.mdx b/absolute-beginners/devops-beginner/git-and-github/github-actions-intro.mdx new file mode 100644 index 0000000..e8e0fef --- /dev/null +++ b/absolute-beginners/devops-beginner/git-and-github/github-actions-intro.mdx @@ -0,0 +1,125 @@ +--- +title: "GitHub Actions: The Ultimate CI/CD Tool for DevOps Beginners" +sidebar_position: 4 +sidebar_label: "4. GitHub Actions Intro" +description: "Discover how GitHub Actions can automate your build, test, and deployment pipeline with ease." +--- + +**GitHub Actions** is an integrated automation platform that allows you to implement **CI/CD (Continuous Integration and Continuous Deployment)** workflows directly within your GitHub repository. It enables you to automate, customize, and execute your software development life cycle right where you store your code. + +## Core Concepts + +To understand GitHub Actions, you need to be familiar with its fundamental building blocks: + +* **Workflows:** A workflow is a configurable automated process that will run one or more jobs. Defined by a YAML file in your `.github/workflows` directory. +* **Events:** An event is a specific activity in a repository that triggers a workflow run (e.g., a push, a pull request, or creating a release). +* **Jobs:** A job is a set of steps in a workflow that is executed on the same runner. Jobs can run in parallel or sequentially. +* **Steps:** An individual task that can run commands or actions. +* **Actions:** A standalone application for the GitHub Actions platform that performs a complex but frequently repeated task. +* **Runners:** A server that runs your workflows when they're triggered. + + +## Getting Started + +To create a workflow, you must place a YAML file inside the `.github/workflows/` directory of your repository. + +### Sample CI Pipeline +This workflow triggers on every push to the `main` branch, installs dependencies, and runs tests. + +```yaml title="ci-pipeline.yml" +name: CodeHarborHub CI +on: + push: + branches: [main] + pull_request: + branches: [main] + +jobs: + build-and-test: + runs-on: ubuntu-latest + steps: + - name: Checkout Code + uses: actions/checkout@v4 + + - name: Setup Node.js + uses: actions/setup-node@v4 + with: + node-version: '20' + cache: 'npm' + + - name: Install Dependencies + run: npm ci + + - name: Run Tests + run: npm test +``` + +## Feature Highlights + +:::tip +Use **Matrix Strategy** to test your application across multiple versions of Node.js or different Operating Systems simultaneously to ensure maximum compatibility. +::: + +### Why use GitHub Actions? + + * **Native Integration:** No need for third-party tools; everything lives inside GitHub. + * **Massive Marketplace:** Access thousands of pre-built actions to speed up your development. + * **Matrix Builds:** Test multiple environments in a single workflow run. + * **Secure Secrets:** Built-in secret management for API keys and deployment tokens. + +## Workflow Lifecycle + + + +A workflow is triggered by an event (e.g., `push`, `pull_request`, `release`) that matches the conditions defined in the workflow YAML file. + + +GitHub provisions a runner (a virtual machine or container) to execute the jobs defined in the workflow. Each job runs its steps sequentially, and multiple jobs can run in parallel. (GitHub selects a runner, pulls your container/environment, and executes your jobs.) + + +After the workflow runs, GitHub provides feedback in the UI, showing which steps passed or failed. You can also view logs for debugging and set up notifications for workflow results. (Real-time logs are streamed to the Actions tab, providing instant feedback on build success or failure.) + + + +## Anatomy of a Workflow File + +Workflows are written in YAML. Here is a basic example of a workflow file (`.github/workflows/hello-world.yml`): + +```yaml title="hello-world.yml" +name: GitHub Actions Demo +run-name: ${{ github.actor }} is testing out GitHub Actions +on: [push] +jobs: + Explore-GitHub-Actions: + runs-on: ubuntu-latest + steps: + - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event." + - name: Check out repository code + uses: actions/checkout@v4 + - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner." + - name: List files in the repository + run: | + ls ${{ github.workspace }} +``` + +## Why use GitHub Actions? + +1. **Fully Integrated:** No need to set up external CI/CD tools; everything lives right where your code does. +2. **Matrix Builds:** Test across multiple operating systems and language versions simultaneously using a `matrix` strategy. +3. **Extensive Marketplace:** Access thousands of pre-built actions created by the community to handle tasks like cloud deployments, notifications, and security scans. +4. **Free for Public Repos:** GitHub provides generous free minutes for public repositories and a solid free tier for private ones. + +## The Workflow Lifecycle + +When you push code to GitHub, the following sequence occurs: + +1. **Trigger:** An event occurs (e.g., `git push`). +2. **Selection:** GitHub looks for workflow files in `.github/workflows` that match the event. +3. **Provisioning:** GitHub provisions a **Runner** (a virtual machine or container). +4. **Execution:** The runner executes the **Jobs** and **Steps** defined in your YAML. +5. **Feedback:** Results are reported back to the GitHub UI (green checkmark or red X). + +:::tip +Always use `actions/checkout` as your first step if your workflow needs to access the code stored in your repository! +::: + diff --git a/absolute-beginners/devops-beginner/git-and-github/gitops-fundamentals.mdx b/absolute-beginners/devops-beginner/git-and-github/gitops-fundamentals.mdx new file mode 100644 index 0000000..f8c30d9 --- /dev/null +++ b/absolute-beginners/devops-beginner/git-and-github/gitops-fundamentals.mdx @@ -0,0 +1,93 @@ +--- +title: "GitOps Fundamentals: The Future of Infrastructure Automation" +sidebar_label: "5. GitOps Fundamentals" +sidebar_position: 5 +description: "Master the principles of GitOps and modern infrastructure automation at CodeHarborHub. Learn how to manage your cloud environments using Git as the single source of truth." +--- + +**GitOps** is an operational framework that takes the best practices used in application development—like **version control**, **collaboration**, and **CI/CD**—and applies them to infrastructure automation. + +At **CodeHarborHub**, we believe GitOps is the future of "Infrastructure as Code" (IaC), allowing teams to manage complex cloud environments using the tools they already love: **Git**. + +## The Four Principles of GitOps + +To implement a true GitOps workflow, your system must adhere to these core pillars: + +1. **Declarative:** The entire system must be described declaratively (e.g., YAML or Terraform), representing the "Desired State." +2. **Versioned & Immutable:** The desired state is stored in a version control system (Git), providing a complete audit trail. +3. **Pulled Automatically:** Software agents automatically pull the desired state declarations from the source. +4. **Continuously Reconciled:** Software agents continuously observe the actual state and automatically act to match the desired state. + +## GitOps vs. Traditional CI/CD + +Understanding the shift from "Push" to "Pull" based deployments is critical for modern **Full-Stack Developers**. + + + + + * **Process:** CI server pushes code/config to the environment. + * **Risk:** CI tool needs high-level credentials (SSH/API keys) to the cluster. + * **Issue:** Configuration drift (manual changes) often goes unnoticed. + + + + + * **Process:** An agent *inside* the cluster pulls updates from Git. + * **Security:** No external credentials needed for the cluster. + * **Reliability:** The agent automatically corrects manual changes (drift) to match Git. + + + + +## Industrial Level Architecture + +In a production-grade GitOps environment, we separate our **Application Code** from our **Infrastructure Configuration**. + +| Component | Responsibility | Tool Example | +| :--- | :--- | :--- | +| **Git Repository** | The Single Source of Truth. | GitHub / GitLab | +| **CI Pipeline** | Builds images and runs tests. | GitHub Actions | +| **Container Registry**| Stores immutable images. | Docker Hub / GHCR | +| **GitOps Controller** | Reconciles Git with the Cluster. | ArgoCD / Flux | + +## Sample Manifest (Desired State) + +Below is a declarative Kubernetes deployment manifest that a GitOps controller would monitor. If someone manually changes the `replicas` to 5 in the cloud console, the controller will automatically scale it back to 3. + +```yaml title="deployment.yaml" +apiVersion: apps/v1 +kind: Deployment +metadata: + name: codeharborhub-web +spec: + replicas: 3 # The Desired State + selector: + matchLabels: + app: web + template: + metadata: + labels: + app: web + spec: + containers: + - name: frontend + image: codeharborhub/web-app:v2.0.1 + ports: + - containerPort: 80 +``` + +## The GitOps Workflow + +1. **Code Change:** A developer submits a Pull Request to the Config Repo. +2. **Review:** The team reviews the infrastructure change in Git. +3. **Merge:** Once merged, the GitOps Controller detects a new commit. +4. **Sync:** The Controller applies the change to the live environment. +5. **Observe:** The Controller monitors for any "Drift" and alerts the team. + +:::info The "GitOps" Secret +GitOps isn't just for Kubernetes! You can apply GitOps principles to any system with a declarative API, including cloud resources via **Terraform** or **Crossplane**. The key is to have a "Controller" that continuously reconciles the actual state with the desired state defined in Git. This means you can manage your entire cloud infrastructure using Git, just like you manage your application code! +::: + +## Learning Challenge + +Try creating a separate repository specifically for "Environment Config." Move your Kubernetes or Docker Compose files there and practice updating your application version only by editing a YAML file in that repo. Set up a GitHub Action to run tests on the config changes and use ArgoCD to automatically deploy those changes to a test cluster. \ No newline at end of file