3.0 KiB
3.0 KiB
title, description, tags, category, created, updated
| title | description | tags | category | created | updated | |||
|---|---|---|---|---|---|---|---|---|
| CI/CD Basics | Introduction to continuous integration and continuous delivery pipelines for application and infrastructure repositories |
|
devops | 2026-03-14 | 2026-03-14 |
CI/CD Basics
Introduction
Continuous integration and continuous delivery reduce manual deployment risk by automating validation, packaging, and release steps. Even small self-hosted projects benefit from predictable pipelines that lint, test, and package changes before they reach live systems.
Purpose
CI/CD pipelines help with:
- Fast feedback on changes
- Repeatable build and test execution
- Safer promotion of artifacts between environments
- Reduced manual drift in deployment procedures
Architecture Overview
A basic pipeline usually includes:
- Trigger: push, pull request, tag, or schedule
- Jobs: isolated units such as lint, test, build, or deploy
- Artifacts: build outputs or packages passed to later stages
- Environments: dev, staging, production, or similar release targets
Typical flow:
Commit -> CI checks -> Build artifact -> Approval or policy gate -> Deploy
Core Concepts
Continuous integration
Every meaningful change should run automated checks quickly and consistently.
Continuous delivery
Artifacts are always kept in a releasable state, even if production deployment requires a manual approval.
Continuous deployment
Every validated change is deployed automatically. This is powerful but requires strong tests, rollback paths, and change confidence.
Configuration Example
GitHub Actions workflow example:
name: ci
on:
pull_request:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm test
Troubleshooting Tips
Pipeline is slow and developers stop trusting it
- Run fast checks early
- Cache dependencies carefully
- Separate heavyweight integration tests from every small change if needed
Deployments succeed but services still break
- Add health checks and post-deploy validation
- Make environment-specific configuration explicit
- Track which artifact version reached which environment
CI and local results disagree
- Match tool versions between local and CI environments
- Keep pipeline setup code in version control
- Avoid hidden mutable runners when reproducibility matters
Best Practices
- Keep CI feedback fast enough to be used during active development
- Require checks before merging to shared branches
- Build once and promote the same artifact when possible
- Separate validation, packaging, and deployment concerns
- Treat pipeline configuration as production code