Cicd Pipelines Practice Exam

Continuous Integration is a development practice where developers frequently merge code changes into a shared repository, often multiple times a day. Each merge triggers an automated build and test process to detect integration errors early.

Key benefits:

• Early bug detection
• Reduced integration conflicts
• Faster feedback loops
• Consistent build process

Continuous Delivery ensures code is always in a deployable state but requires a manual approval step before production release.

Continuous Deployment goes further: every change that passes all pipeline stages is automatically deployed to production with no human intervention.

Delivery = ready to deploy on demand
Deployment = auto-deployed every time

A standard CI/CD pipeline includes these stages:

• Source – code checkout from version control
• Build – compile code and resolve dependencies
• Test – run unit, integration, and end-to-end tests
• Static Analysis – linting, code quality checks
• Security Scan – SAST, dependency scanning
• Package – create deployable artifacts
• Deploy – push to staging or production
• Release – make available to users

A GitHub Actions workflow is an automated process defined in a YAML file under .github/workflows/. It is triggered by events such as push, pull_request, or schedule.

A workflow contains one or more jobs, each consisting of steps that run commands or use actions.

Example trigger:
on: [push, pull_request]

• Jobs – independent units of work that run on a runner. Jobs run in parallel by default but can depend on each other using needs.
• Steps – individual tasks within a job, executed sequentially. Each step either runs a shell command (run:) or uses an action (uses:).
• Actions – reusable packaged tasks from the GitHub Marketplace or custom repositories, referenced as uses: actions/checkout@v4.