#03 GIT - CI/CD handson

Day 1: Zero to Hero DevOps

Understanding the "What," "Why," and the Culture of Modern Software Delivery

CONCEPT

What is DevOps?

Forget the complex textbook definitions. At its core, DevOps is a culture or practice adopted by organizations to increase their ability to deliver applications quickly [3, 4].

"DevOps is a process of improving application delivery by ensuring proper automation, quality, continuous monitoring, and testing." [5, 6]

The goal is simple: Reduce the time it takes to move code from a developer's laptop to the customer (e.g., from 2 weeks down to 1 week) without sacrificing quality [4, 6].

HISTORY

Why did DevOps Emerge?

Ten years ago, software delivery was a manual, fragmented process involving separate silos [7, 8]:

• System Administrators: Created servers manually [9, 10].
• Build & Release Engineers: Deployed the code [9, 11].
• Testers: Verified the application manually [9].

This manual effort led to slow communication and inefficient systems [12, 13]. DevOps evolved to automate this entire pipeline, replacing multiple disconnected teams with one unified culture of delivery [12, 13].

CORE PRINCIPLES

The Four Pillars of DevOps

To succeed as a DevOps engineer, you must focus on these four areas [14, 15]:

1. Automation: Reducing manual labor with tools like GitHub Actions [1, 2].
2. Quality: Ensuring the code meets standards before delivery [1].
3. Monitoring & Observability: Reporting back on the health of the system [5, 14].
4. Testing: Continuous testing to validate that automation is correct [14].

PRACTICE

Hands-on: Automating Your First Check

To demonstrate the Automation pillar, we will use a GitHub Actions workflow to automatically greet you every time you push code [2, 16].

The Code (.github/workflows/devops-day1.yml)

name: Day1-Automation
on: [push] # Trigger on every push
jobs:
  check-quality:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
      
      - name: Automated Greeting
        run: echo "DevOps Automation Started for ${{ github.actor }}!"
        

How-to Run

1. Create a new GitHub repository.
2. Create a folder .github, and inside it, a folder workflows.
3. Create a file named devops-day1.yml and paste the code above.
4. Commit and push. Go to the Actions tab to see your first automated DevOps process! [2]

Undergrad Challenge: Modify the workflow to include a second step that prints "System Monitoring Active" and the current date. This simulates two of the four pillars: Automation and Monitoring [14].

CI - QUALITY PILLAR

Continuous Integration: The Automated Quality Gate

As discussed, Quality and Testing are core pillars of DevOps [4]. CI is the practice of automatically building and testing your code every time a team member makes a change [5]. This ensures that "bugs" are caught early before they ever reach a customer [6, 7].

The Code (.github/workflows/ci-testing.yml)

name: CI-Quality-Check
on:
  pull_request:
    branches: [ "main" ] # Run when someone wants to merge code
jobs:
  test-code:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
      
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Dependencies
        run: npm install

      - name: Run Unit Tests
        run: npm test
        

How-to Run

1. Create a simple Node.js project (npm init -y) in your repo.
2. Add a basic test script in your package.json.
3. Create a Pull Request. GitHub will automatically run your tests before allowing the merge.

Hands-on Exercise: Deliberately write a failing test in your code and push it. Observe how the CI Pipeline blocks the Pull Request, preventing "bad code" from reaching the main branch [7, 8].

CD - DELIVERY PILLAR

Continuous Deployment: Shipping at Speed

The end goal of DevOps is Delivery [9]. While CI checks for quality, Continuous Deployment (CD) automates the release of that checked code to a production environment or package registry [5, 10]. This reduces the delivery time from 10 days to just minutes [1, 9].

The Code (.github/workflows/cd-deploy.yml)

name: CD-Deploy-Package
on:
  push:
    branches: [ "main" ] # Run only after code is merged to main
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Build Artifact
        run: |
          mkdir -p dist
          echo "Production Build version ${{ github.run_number }}" > dist/index.html
      
      - name: Upload Build Artifact
        uses: actions/upload-artifact@v4
        with:
          name: production-site
          path: dist/
        

How-to Run

This workflow simulates "building" your app. Once you push to the main branch, GitHub Actions will create a "Production Build" and store it as a Workflow Artifact [5].

Undergrad Challenge: Combine CI and CD! Research needs: [job_name] syntax in GitHub Actions to make the Deploy job only run if the Test job succeeds. This ensures you never deploy broken code [4, 8].

Based on Abhishek Veeramalla's DevOps Zero to Hero Course | Day 1