CI/CD (continuous integration and continuous deployment) is described as a complex infrastructure project requiring elaborate pipelines, multiple environments, and sophisticated tooling.
For a small team (5-20 people), the minimum that works is much simpler.
What CI/CD actually provides
Continuous integration: Every code change is automatically tested. Errors are caught before they are merged. This prevents broken code from reaching production.
Continuous deployment: Code that passes tests is automatically deployed to production. No manual steps. No forgotten deploys. No deployment window.
These two things together mean your team ships faster and with fewer defects.
The minimum viable setup
1. A git repository. GitHub, GitLab, or Gitea. Any will do. You probably already have this.
2. A CI tool that watches the repository. GitHub Actions (free), GitLab CI (free), or Jenkins (self-hosted). When code is pushed, the tool runs tests and reports results. GitHub Actions is simplest for teams already using GitHub.
3. Tests. Automated tests that verify the code works. Unit tests, integration tests, or both. The tests must run in under 5 minutes ideally, 10 minutes maximum.
4. Deployment script or tool. A script that builds the app and deploys it. Docker plus docker-compose, or a shell script, or a tool like Capistrano. Anything automated.
5. A deployment server or managed hosting. Somewhere to deploy to. This could be a VPS, a PaaS like Heroku, or a container registry.
That is it. Five things. Most of them you already have or can set up in a few hours.
How it works
1. Developer writes code. 2. Developer pushes to git. 3. CI tool automatically runs tests. 4. If tests pass, deployment script runs automatically, deploys code to production. 5. If tests fail, deployment stops. Developer is alerted. Developer fixes code.
The entire flow can be end-to-end in 15-30 minutes. For a small team, this often means “push code and it is in production within 30 minutes.”
The configuration
Most of this is a config file. GitHub Actions uses .github/workflows/deploy.yml. It looks like:
`yaml name: Deploy on: [push] jobs: test: runs-on: ubuntu-latest steps:
- uses: actions/checkout@v2
- run: npm test
- run: npm run build
- run: deploy.sh
`
That is all. Twenty lines of config. It says: on every push, run tests, build, and deploy.
What you should automate
Tests. Always. This is the highest leverage.
Building. Always. Manual builds are error-prone.
Deployment. For small teams, automate direct to production. For larger teams, automate to staging first, then manual promotion to production.
Schema migrations. If you have a database, migrations should run as part of deployment.
Notifications. Slack notification when a deploy happens. Email notification if a test fails.
What you shouldn’t automate (yet)
Complex multi-stage deployments. Once you have basic CI/CD working and it is reliable, add complexity.
Blue-green deployments. Nice to have. Not necessary until you care about zero-downtime deploys.
Canary deployments. Gradually rolling out to a percentage of traffic. Unnecessary for small teams.
Start simple. Add complexity when you have measured that you need it.
Common mistakes
Tests that are slow. If your test suite takes 30 minutes to run, CI becomes painful. Invest in fast tests.
Tests that are flaky. If tests pass then fail for no reason, the team stops trusting them and stops using them. Invest in deterministic tests.
Deployments that can fail. If deployments sometimes fail and require manual intervention, automation loses its value. Invest in bulletproof deploys.
No rollback plan. If code in production has a bug, how fast can you revert? Ideal is under 5 minutes. If it takes hours, you are not ready for continuous deployment.
Deployment without tests. If you automate deployment without having confidence in your tests, you are automating errors into production. Tests first.
Cost
GitHub Actions: free for public repos, £0.24/hour for private repos. Usually comes out to £5-20/month.
Self-hosted CI (Jenkins): free but requires a server (£20-50/month).
Heroku or equivalent PaaS: £50-200/month depending on app size.
Total for a small app: £50-100/month. Paid by the time you avoid your first manual deployment disaster.
Security
Your CI/CD has access to deploy to production. Protect it.
- Never put credentials in code. Use environment variables or a secrets manager.
- Limit who can merge to main branch. Code review is still valuable.
- Log all deployments. Know who deployed what when.
- Have a rollback procedure. Know how to revert a bad deploy.
After you have the basics
Once this is working and your team trusts it, improvements:
- Deploy to staging before production
- Automated tests for staging
- Manual approval for production (Slack button to approve)
- Deployment notifications
- Health checks after deployment (automated rollback if health checks fail)
- Metrics and monitoring
None of these are necessary for the MVP. All of them are valuable once basics work.
The realistic impact
A team with CI/CD ships faster, with fewer defects, and with less stress. Developers focus on features instead of deployment logistics. Deployment becomes boring (which is good).
The team without CI/CD ships slower, with more defects, and with more stress. Deployment is stressful and manual. Bugs make it into production.
The difference is visible after two weeks.
The minimum summary
- Push to git = tests run
- Tests pass = code deploys
- Tests fail = code does not deploy
- Developer is notified immediately
This is enough for most small teams. Everything else is optimisation.