Jan Mikoláš
Glossary
CI/CD: from a code change to a verified deployment
The goal is not a green pipeline, but fast, repeatable feedback on whether a change has broken the project’s rules.
Short definition
Automating the verification and delivery of changes.
CI, or Continuous Integration, means frequently merging changes into a shared repository with an automated build and checks. A pull request therefore receives the same verification as a change after merge, and the result is tied to a specific commit.
Unit tests and focused integration tests are typical CI checks; passing them does not replace human review or a deployment decision.
CD has two meanings. Continuous Delivery keeps a change ready for release, but a production release can wait for approval. Continuous Deployment goes further: once specified automated conditions pass, the change is deployed to production automatically.
Use cases
Why a pipeline is valuable
Automation should replace repeatable manual steps, not the team’s technical judgement.
- the same set of checks for a pull request and merge
- a traceable artefact tied to a commit
- a repeatable process for staging and production
- required checks and protection of the main branch
- separate environments, secrets, and permissions
- finding an error quickly and close to the change
Practical example
Changing order validation in a PHP online store
After a pull request is opened, CI verifies composer.json and the lock file on a clean runner, installs dependencies, and runs linting, PHPStan, PHPUnit, and Deptrac. Failure of any required check means the change is not ready to merge.
After merge, a versioned artefact is created. Staging verifies a compatible migration and health endpoint. Production deployment can require environment approval; afterwards, a smoke test checks a safe flow without creating a test order. The team must know the previous artefact and whether returning to it is compatible with the database.
Typical pipeline
From commit to operational verification
The exact shape should follow application risk, not the number of fashionable jobs.
- Dependencies Running Composer validate and installing dependencies from the lock file on a clean runner.
- Fast checks Linting and style checks give quick feedback on code and configuration.
- Quality PHPStan, PHPUnit, and optionally Deptrac verify types, behaviour, and architectural boundaries.
- Artefact and staging The same image or artefact is deployed, migrations are checked, and a safe smoke test runs.
- Production and oversight Controlled deployment, monitoring, logs, and a known rollback procedure.
Important features
Checks, deployment, and safe change
Having a workflow file does not make the process sound by itself.
Merge gate
CI is more than running tests. If a protected branch allows merges without required checks, their result carries no real weight.
The same artefact
Promoting the same verified artefact to staging and production is safer than building something new for each environment.
Migrations and rollback
Migrations are part of the change. Reverting an image does not restore deleted or incompatibly changed data; an expand–migrate–contract process helps with risky changes.
Secrets and permissions
Production keys do not belong in the repository or logs. An environment can require approval and release secrets only after protection rules pass.
Benefits and limitations
Automation executes the process the team has defined
Benefits
- repeatable verification of every change
- errors visible in the pull request before release
- a release independent of one person’s local process
- traceability among the commit, artefact, checks, and deployment
Common mistakes
- a green pipeline with little or unsuitable coverage
- flaky tests that are merely rerun instead of fixed
- a main branch without branch protection
- secrets leaked through debug output or an untrusted action
- a migration that prevents a safe rollback
Scope of use
The pipeline’s scope should match the risk of the change.
A small project does not need ten parallel jobs. The minimum may be dependency installation, static analysis, tests, and a repeatable deployment. For an application with orders, payments, and integrations, adding staging, architectural checks, branch protection, and deliberately designed migrations is proportionate.
Automatic production deployment is not a goal in itself. Without observability, safe rollback, and control of secrets, it only deploys a faulty change more quickly.
What to keep in mind
What should pass before release
Checks should be fast, reproducible, and understandable to the developer.
- Composer validation and dependency installation from the lock file
- linting, code style, and static analysis
- unit tests and important integration tests
- architectural checks where they protect real boundaries
- a versioned artefact, compatible migrations, and a smoke test
- a protected branch, restricted permissions, and a traceable rollback
Common questions
What CI/CD guarantees
What is the difference between continuous delivery and continuous deployment?
Delivery keeps the application ready for release; production deployment can wait for approval. Deployment releases the change automatically after successful gates.
Does CI replace code review?
No. Automation finds repeatable errors but does not understand the business intent, clarity of the solution, or a poor product trade-off.
Does CI make sense for a small PHP project?
Usually yes, at least for installing dependencies, static analysis, and tests. For a very short one-off script, the investment still needs to be proportionate.
Can rollback always fix a faulty migration?
No. If a migration removed or irreversibly changed data, reverting the application is not enough. Compatible steps, a backup, and a recovery plan therefore matter.
How I use CI and quality checks in practice
Automated checks belong in the normal development flow.
The public scheduling project shows a workflow with tests and quality checks; it is an example of CI for source code, not a claim about a particular production deployment.