Skip to main content

CI-CD Fundamentals

GitHub Actions is a powerful, native CI/CD platform built directly into GitHub. It allows you to automate your software development workflows—including building, testing, and deploying code—whenever specific events occur in your repository.

CI/CD Pipeline

Core Concepts​

To understand how GitHub Actions works, it is helpful to know its primary components:

  • Workflow: An automated process defined by a YAML file (stored in .github/workflows/). It contains one or more jobs and can be triggered by events like a push, pull_request, or even a scheduled time.
  • Event: A specific activity in your repository that triggers a workflow (e.g., merging a pull request, opening an issue, or pushing code).
  • Job: A set of steps that execute on the same runner. Jobs can run sequentially or in parallel.
  • Step: An individual task within a job. A step can run a command (script) or an "Action".
  • Action: A reusable, pre-built piece of logic that simplifies your workflow (e.g., setting up a specific programming language or deploying to a cloud provider).
  • Runner: The server (machine) that executes your workflow. GitHub provides hosted runners (Linux, Windows, macOS), or you can use your own self-hosted runners.

How CI/CD Works with GitHub Actions​

  1. Continuous Integration (CI): When you push code or open a pull request, GitHub Actions automatically triggers a workflow to build your application and run tests. This ensures that new changes do not break existing functionality.
  2. Continuous Delivery (CD): Once the code passes automated tests, the workflow can automatically package the application and deploy it to your staging or production environments.

Why Use GitHub Actions?​

  • Native Integration: Because it is built into GitHub, you don't need to manage separate infrastructure or external CI/CD tools.
  • Flexibility: It supports any language (Node.js, Python, Java, Go, etc.) and allows you to run workflows in containers or virtual machines.