Continuous integration and delivery are often described in terms of large engineering organisations. The underlying practice suits small teams even better, because it removes the deployment fear that slows them most.
Start with the build
Before automating deployment, make the build reliable. Every commit should install dependencies cleanly, run the test suite and fail loudly. A pipeline that is red half the time trains everyone to ignore it.
A pipeline worth having
- Install dependencies from a lockfile
- Run static analysis and the test suite
- Build assets exactly once and reuse the artefact
- Deploy the same artefact to staging, then production
Deploy small and often
Small changes are easier to review, easier to test and dramatically easier to roll back. Teams that deploy weekly accumulate risk; teams that deploy daily rarely have a bad night.
Make rollback boring
Keep the previous release available and switch back with one command. Database changes need care: deploy additive migrations first, then the code that uses them, so the two can be rolled back independently.
What to automate next
Once deployment is dull, automate the checks that catch regressions: smoke tests against staging, a performance budget, and an alert if error rates rise after a release.
The goal is not deployment speed for its own sake. It is making releases so ordinary that nobody schedules them for a Friday evening.
Where to start
Automate one thing this week: running your tests on every push. Everything else in the pipeline builds on that habit.
