CI/CD Concepts and GitHub Actions Fundamentals

What Is Continuous Integration?

When a team of developers each writes code on their own machine and then tries to merge everything together at the end of a sprint, conflicts pile up and bugs hide until the last moment. Continuous Integration (CI) solves this by having every developer push small changes to a shared repository frequently—often many times a day. Each push automatically triggers a pipeline that compiles the code and runs a suite of automated tests. If something breaks, the team finds out within minutes, not weeks.

The goal of CI is simple: keep the shared codebase in a working state at all times.

What Is Continuous Deployment?

Continuous Deployment (CD) extends CI by automatically releasing code that passes all tests to a live environment. In some teams this means every green build goes straight to production. In others, there is an intermediate staging environment where the build is reviewed or given a final smoke test before the final promotion to production. You will also see the term Continuous Delivery, which means the release step is automated up to the point of production but requires a manual approval click to go live. The distinction matters for exam questions, so remember: deployment = fully automatic; delivery = automated pipeline, manual gate.

Stages of a CI/CD Pipeline

A pipeline is the ordered sequence of automated steps that runs every time code is pushed. The stages you need to know for this lesson are:

1. Code Push – A developer commits and pushes changes to the version-control repository (e.g., GitHub).

2. Trigger – The CI/CD platform detects the push (or a pull-request event, a tag, or a scheduled time) and starts the pipeline.

3. Build – The source code is compiled or bundled. For interpreted languages such as Python, this stage may install dependencies and lint the code instead of compiling.

4. Automated Tests – Unit tests, integration tests, and any security scans run automatically. A single failing test stops the pipeline and notifies the team.

5. Deploy to Staging – The built artifact is deployed to a staging server that mirrors production. Testers or automated end-to-end tests verify behavior in a realistic environment.

6. Deploy to Production – After staging is approved, the same artifact is deployed to the live production environment. Using the same artifact (not rebuilding) is a key best practice—it guarantees what was tested is exactly what ships.

7. Rollback Path – If production monitoring detects a problem, the pipeline can redeploy the last known-good artifact automatically or with a single command. A rollback plan must exist before you deploy, not after something goes wrong.

GitHub Actions Overview

GitHub Actions is a CI/CD platform built directly into GitHub. Workflows are defined in YAML files stored in the `.github/workflows/` directory of a repository. GitHub reads those files and runs them on cloud-hosted virtual machines called runners.

A workflow file has three essential sections:

• `on:` – Defines the event that triggers the workflow (e.g., `push`, `pull_request`, `schedule`).
• `jobs:` – One or more named jobs. Jobs run in parallel by default; you can add a `needs:` key to force sequential order.
• `steps:` – The ordered list of tasks inside a job. Each step either uses a pre-built Action from the GitHub Marketplace or runs a shell command directly.

Reading a Workflow File

Here is a minimal annotated example:

```yaml

name: Deploy App # Human-readable name shown in the GitHub UI

on:

push:

branches: [main] # Trigger: any push to the main branch

jobs:

build-and-deploy:

runs-on: ubuntu-latest # Runner OS: the latest Ubuntu image

steps:

• name: Check out code

uses: actions/checkout@v4 # Pre-built Action; clones the repo

• name: Set up Python

uses: actions/setup-python@v5

with:

python-version: '3.12'

• name: Install dependencies

run: pip install -r requirements.txt

• name: Run tests

run: pytest --tb=short

• name: Deploy to production

run: ./scripts/deploy.sh

env:

API_KEY: ${{ secrets.DEPLOY_API_KEY }} # Secret stored in GitHub, never in code

```

Key points: `uses:` pulls a versioned, community-maintained Action; `run:` executes an arbitrary shell command on the runner. If any step exits with a non-zero code, GitHub Actions marks that step as failed, stops the job, and does not proceed to later steps—preventing a broken build from reaching production.

Security and Safe Practices

CI/CD pipelines frequently handle credentials, API keys, and server access. Follow these rules:

• Never hard-code secrets in a YAML file or source code. Store them as encrypted GitHub Secrets and reference them with `${{ secrets.NAME }}`.
• Pin Action versions using a commit SHA or a specific version tag (e.g., `@v4`) to prevent supply-chain attacks from a compromised Action update.
• Least privilege – the deployment credentials used by the pipeline should have only the permissions needed for that task, nothing more.
• Review third-party Actions before adding them to a workflow, just as you would review any third-party library.

These habits protect both the production environment and any user data it holds.