What is CI/CD?
CI/CD stands for Continuous Integration and Continuous Deployment/Delivery.
Every time you push code, your project is automatically:
- Tested
- Built
- Deployed (if all tests pass)
This helps you:
- Catch bugs early
- Ship features faster
- Reduce manual steps and human errors
Why use CI/CD?
By automating tests and deployments, you:
- Find bugs before they reach users
- Deploy quickly and safely
- Get feedback on every push
- Focus on writing code, not running scripts
How does CI/CD work with Git?
- Every time you push to your Git repository:
- The CI/CD service (e.g., GitHub Actions, GitLab CI) sees the change.
It starts your pipeline:
- Runs tests
- Builds the project
- (Optionally) deploys automatically
3.If something fails, you’re notified right away.
Typical CI/CD Workflow
[Developer] --push--> [Git Repository]
--triggers--> [CI/CD Pipeline: Test → Build → Deploy]
Popular CI/CD Services
- GitHub Actions: Native to GitHub, uses YAML workflows in .github/workflows/
- GitLab CI/CD: Built into GitLab, uses .gitlab-ci.yml
- CircleCI: Integrates with GitHub/GitLab, easy for many languages
- Azure Pipelines: Supports many platforms, integrates with Azure & GitHub
Key CI/CD Concepts
Jobs
A job groups multiple steps and runs on a runner.
Example (GitHub Actions):
jobs:
build:
runs-on: ubuntu-latest
steps:
# steps go here
Steps
Each step is a single command or action.
Example:
steps:
- uses: actions/checkout@v3
- name: Run tests
run: npm test
Runners
A runner is the server that executes your jobs.
You can:
- Use default runners (provided by GitHub, GitLab, etc.)
- Host your own for more control
Example:
runs-on: ubuntu-latest
Triggers
Triggers decide when workflows run.
Common triggers:
- push: on every push
- pull_request: when a PR is opened or updated
Example:
on:
push:
pull_request:
Environment Variables & Secrets
Use:
Environment variables for general config (e.g., NODE_ENV)
Secrets for sensitive data (e.g., API keys)
Never commit secrets to code.
Example:
env:
NODE_ENV: production
API_KEY: ${{ secrets.API_KEY }}
Build Logs
CI/CD tools show logs for every job and step.
- Helps debug why a build failed
- In GitHub Actions: view logs from the Actions tab
Skipping CI
Skip CI/CD for minor commits by adding [skip ci] to your commit message.
Example:
git commit -m "Update docs [skip ci]"
Badges
Add a badge to your README to show build status.
Example (GitHub Actions):
Example CI Workflow (GitHub Actions)
# .github/workflows/ci.yml
name: CI # Workflow name
on: [push] # Trigger: every push
jobs:
build: # Job name
runs-on: ubuntu-latest # Runner
steps:
- uses: actions/checkout@v3 # Step: checkout code
- name: Run tests # Step name
run: npm test # Command to run
Quick breakdown:
Key Meaning
name Display name in GitHub
on Defines when to run (here: on push)
jobs Groups jobs
build Job name
runs-on OS for the runner
steps List of commands/actions
uses Use a pre-made action
run Shell command to run
Troubleshooting & Best Practices
- Check logs if builds fail
- Double-check secrets & environment variables
- Rerun failed jobs from your CI/CD dashboard
- Start simple: test first, add deployment later
- Keep secrets out of code
- Use badges to show build status
