Today, software is rarely delivered in large packages every few months. Instead, small changes flow continuously into the shared code and are checked automatically. CI/CD describes the practices and the automation behind this, often referred to as a pipeline. Microsoft counts CI/CD among the core practices of DevOps, the close integration of development and operations. The foundation is a version control system such as Git.
The building blocks
- Continuous integration (CI): According to GitHub, a practice in which code is frequently committed to a shared repository. Every change is built and tested automatically. As a result, errors are detected early, while they are still cheap to fix.
- Continuous delivery (CD): Code is automatically built, tested, and delivered to one or more test and production environments. The goal is for the code to be deployable at any time. The release to production can deliberately remain a human step.
- Continuous deployment: Every change that passes all checks goes to production automatically. Microsoft points out that this requires robust automated tests and careful planning and does not suit every team.
What a pipeline looks like
- Trigger: A push or a pull request starts the pipeline.
- Build: Install dependencies, for example with Composer, and build the application.
- Check: Unit tests, static analysis, format checks, scanning dependencies for known vulnerabilities, and searching for accidentally committed credentials.
- Review: A human checks the change in a code review before it is merged into the main branch.
- Create an artifact: A versioned package or container image is produced that moves unchanged through all environments.
- Deliver: First to a test environment with integration and UI tests, then to production after approval.
- Observe: After delivery, monitoring checks error rates and response times. A path back to the previous version is prepared.
Common tools are GitHub Actions, GitLab CI/CD, and Azure Pipelines.
Benefits for SMEs
- Less manual work and fewer errors: Recurring steps run the same way every time, regardless of who is on duty.
- Faster security updates: A library update is tested and delivered without anyone having to set aside an evening for it.
- Traceability: Who changed, reviewed, and delivered what, and when? This helps with error analysis and with providing evidence to customers or auditors.
- Small teams benefit in particular: Knowledge lives in the pipeline instead of only in one person's head.
Pipeline security
A pipeline has access to source code, credentials, and production systems and is therefore a target in its own right. OWASP maintains a dedicated list of the ten most important CI/CD risks, including insufficient flow control mechanisms, inadequate identity and access management, dependency chain abuse, poisoned pipeline execution, and insufficient credential hygiene. Concrete measures:
- No way around the checks: Protected branches with mandatory reviews and mandatory checks, no direct changes to production.
- Minimal permissions: GitHub recommends configuring the automatic token as read-only by default and granting higher permissions specifically per job, following least privilege.
- Pin third-party components: According to GitHub, pin third-party actions to a full commit hash and review their source code.
- No unchecked input in scripts: Do not insert pull request titles or descriptions directly into commands.
- Store secrets properly: Keep credentials only in the platform's secret store, separated per environment and rotated regularly.
- Log: Store runs and approvals in a traceable way.
Typical pitfalls
Unreliable tests that fail at random undermine trust in the pipeline. Long run times tempt teams to skip checks. Differences between test and production environments can be reduced with Infrastructure as Code.
How it differs
DevOps describes culture and collaboration; CI/CD is the technical practice within it. In change management, a verified pipeline can serve as the path for standard changes, while larger changes still need their own approval.
How TOMORIS relates
TOMORIS develops its own software via the internal platform Werft: requirements go through isolated working copies, tests, and reviewable pull requests, while approval and deployment remain separate steps. For your software project, you can get started under Custom Software.
Sources
- GitHub Docs: Continuous integration
- GitHub Docs: Secure use reference for GitHub Actions
- Microsoft Learn: What is DevOps?
- Microsoft Learn: What is continuous delivery?
- Microsoft Learn: Get started with DevOps architecture design
- OWASP: Top 10 CI/CD Security Risks
- NIST: SP 800-218, Secure Software Development Framework 1.1