Beta

GitHub Actions

Introduction

Basics of CI CD

Continuous Integration and Continuous Deployment (CI/CD) streamline modern software delivery by automating builds, tests, and deployments. With a robust CI/CD pipeline, teams catch issues early, maintain consistent environments, and accelerate time to market.

Git Workflow for Feature Development

All source code is versioned in a Git repository, often hosted on platforms like GitHub or GitLab. Teams typically follow this branching strategy:

  1. main (or master): Production-ready code
  2. feature/*: Isolated branches for new work

When implementing a new feature:

  1. Create a feature branch off main.
  2. Commit code and open a Pull Request (PR).
  3. Run automated checks via CI.
  4. Peer-review and approve the PR.
  5. Merge back into main and trigger deployment.

Note

Keeping main always deployable reduces integration headaches and rollbacks.

The image illustrates a workflow for continuous integration, highlighting the process from feature branches to production, and lists challenges like delayed testing, inefficient deployment, and quality assurance issues without CI.

Without CI/CD, manual testing and deployments introduce risks:

  • Delayed feedback and bug discovery
  • Configuration drift between environments
  • Heavy reliance on manual QA

Continuous Integration

Continuous Integration (CI) automates the moment code is pushed:

  1. Developer opens a PR against main.

  2. A CI pipeline runs:

    StagePurposeExample Tool
    Unit TestsVerify individual componentsJest, JUnit
    Dependency ScanningIdentify outdated or vulnerable libsDependabot, Snyk
    Build & Artifact CreationCompile code and produce deployablesDocker, Maven
    Code Quality & SecurityStatic analysis and vulnerability checkSonarQube, CodeQL

  3. Any failure halts the merge and notifies the author.

  4. On success, the PR is merged and triggers a final CI run on the updated main branch.

The image illustrates a continuous integration workflow, showing steps from feature branch creation to production deployment, including unit testing, dependency scanning, and code scanning.

Imagine developers Alice and Bob each working on separate feature branches. Their individual CI runs validate changes in isolation. After merging both PRs, a collective CI run on main ensures compatibility across all contributions.

Continuous Delivery vs Continuous Deployment

After CI, the next stage is CD—either Continuous Delivery or Continuous Deployment:

  1. Continuous Delivery

    • Deployments to staging happen automatically.
    • Production releases require manual approval.

  2. Continuous Deployment

    • Every successful build on main is pushed straight to production without human intervention.

A typical CD pipeline:

  • Deploy to staging → run integration/regression tests
  • (Optional) Manual approval for production
  • Deploy to production

Warning

Automated production deployments can speed delivery but require robust rollback and monitoring strategies.

The image illustrates a continuous deployment/delivery pipeline, showing the process from committing code to deploying it in production and staging environments, including steps like code review, continuous integration, and testing.

Further Reading

Watch Video

Watch video content

Previous
Introducing Github Actions
Next
Create amp Explore GitHub Account