What a CI/CD pipeline is and when a small team needs DevOps
If your developers deploy by copying files to a server over SFTP, or if releases happen “when Alex has time on Friday evening”, you are not alone. Many small teams work like this until a bad release takes the product down. CI/CD is the practice that makes releases boring, and boring releases are exactly what you want.
CI: continuous integration
Every time a developer pushes code, an automated system builds the application and runs the tests. If something is broken, the team learns about it within minutes, not after the release. Typical steps:
- Install dependencies and build the application.
- Run automated tests and code quality checks.
- Scan dependencies for known vulnerabilities.
- Build a Docker image or a release package.
CD: continuous delivery and deployment
Once the build passes, the same pipeline deploys it: first to a staging environment, then to production, either automatically or with one click. The deployment is the same every time, so nobody forgets a step, and rolling back means deploying the previous version.
A simple example
A small company with a web application on GitHub can start with a pipeline in GitHub Actions:
- On every pull request: build, test and comment the result.
- On merge to the main branch: build a Docker image and push it to a registry.
- Deploy the image to staging automatically.
- Deploy to production after a manual approval.
The pipeline itself is a short configuration file in the repository, so it is versioned and reviewed like any other code.
What it costs
For a small team, the tools are often free or cheap: GitHub Actions and GitLab CI include free minutes, and container registries cost little. The real cost is engineering time to set it up, typically 10 to 30 hours for a first project, plus some maintenance. That is why we offer DevOps as monthly hours rather than a large project.
Signs you need it now
- Releases are stressful and happen rarely because of that.
- Only one person knows how to deploy.
- Bugs reach customers that a simple test would have caught.
- Staging and production behave differently.
- You cannot tell which version is running in production.
What comes after CI/CD
Once releases are automated, the next steps are usually monitoring and alerts (so you know about problems before users), infrastructure as code (so servers can be rebuilt from scratch) and containers for consistent environments. We describe the second one in our article on Terraform and Ansible.
Our DevOps Starter plan includes a CI/CD pipeline for one project with 10 engineer hours a month.