Introduction to GitHub Actions and CI/CD

# CHAPTER 1

Introduction to GitHub Actions and CI/CD #

1. Introduction #

2. Learning Objectives #

• Define Continuous Integration (CI) and Continuous Deployment (CD).

• Explain what GitHub Actions is and why it disrupts traditional CI/CD tools.

• Understand the core concepts of workflow automation.

• Appreciate the benefits of having code and automation in the same platform.

3. Beginner-Friendly Explanation #

• The Old Way (Manual): You finish writing a chapter. You email it to your editor. You wait two days for them to check for typos. Then you email it to the publisher. If you made a mistake, the publisher rejects it, and you start over.

• The DevOps Way (CI/CD):

• CI (Continuous Integration): As soon as you save the document, an automated grammar-checking robot instantly scans your chapter. If you misspelled a word, it alerts you in 5 seconds.

• CD (Continuous Deployment): If the robot finds zero errors, it automatically formats the book and sends it straight to the printing press.

• GitHub Actions: This is the robot built directly into your word processor. You don't need to email the document anywhere; the robot is already watching your cursor.

4. What is CI/CD? #

Continuous Integration (CI): When multiple developers work on the same app, their code often conflicts. CI means developers merge their code into a central repository (GitHub) several times a day. Every time they merge, GitHub Actions automatically wakes up and runs automated tests to ensure the new code didn't break the old code.

Continuous Delivery vs. Deployment (CD):

• Continuous Delivery: Once the code passes the CI tests, GitHub Actions packages the application and places it in a staging area, waiting for a human to click "Deploy."

• Continuous Deployment: There is no human intervention. If the code passes all automated tests, GitHub Actions pushes it straight to live production servers. Companies like Amazon deploy code thousands of times a day using this method.

5. Why GitHub Actions? #

1. 1. Zero Maintenance: You don't have to install or manage a server. GitHub hosts the computers (Runners) that execute your automation.

1. 2. Native Integration: It lives right next to your code. You can trigger automations based on GitHub-specific events (e.g., "Run this script when a new Issue is opened" or "Deploy when a Pull Request is merged").

1. 3. The Community Marketplace: If you need to deploy to AWS, you don't have to write a complex script. You can just search the GitHub Marketplace and borrow a script written by AWS engineers.

6. Mini Project: Create First GitHub Actions Workflow #

Step-by-Step Walkthrough:

1. 1. Create a new repository on GitHub (e.g., my-first-action).

1. 2. Click on the Actions tab at the top of your repository.

1. 3. Click the link to "set up a workflow yourself".

1. 4. GitHub will create a file named main.yml inside a special hidden folder: .github/workflows/.

1. 5. Delete the default code and paste this minimal script:

name: My First Workflow
on: [push] # This triggers the workflow every time you push code

jobs:
  hello-world-job:
    runs-on: ubuntu-latest
    steps:
      - name: Say Hello
        run: echo "Hello, World! Welcome to DevOps."

1. 6. Click Commit changes (in the top right).

1. 7. Go back to the Actions tab. You will see a green checkmark next to your commit! Click on it, then click on hello-world-job to see the terminal output where GitHub printed your message.

7. Real-World Scenarios #

8. Best Practices #

• Everything as Code: Treat your automation scripts with the same respect as your application code. Because GitHub Actions workflows are just YAML files stored in your repository, they undergo version control. If you break your deployment script, you can easily revert to the previous Git commit.

9. Security Recommendations #

• Public vs. Private: GitHub Actions is free for public open-source repositories. For private repositories, you get a generous quota of free minutes per month. Be careful not to run infinite loops in your workflows, or you will burn through your quota and potentially incur charges!

10. Troubleshooting Tips #

• The Hidden Folder: For GitHub to recognize your workflow, the YAML file *must* be placed exactly inside the .github/workflows/ directory at the root of your repository. If you misspell it as .github/workflow/ (singular), GitHub will ignore the file entirely.

11. Exercises #

1. 1. Explain the difference between Continuous Delivery and Continuous Deployment.

1. 2. What is the primary architectural difference between GitHub Actions and a traditional CI/CD tool like Jenkins?

12. FAQs #

13. Interview Questions #

• Q: Describe the CI/CD pipeline lifecycle from the moment a developer commits code to the repository to the moment it reaches the end-user.

• Q: Why might an enterprise choose to migrate from a self-hosted Jenkins infrastructure to GitHub Actions? What are the operational trade-offs?

14. Summary #

15. Next Chapter Recommendation #