If You’re Deploying Manually, You’re Doing It Wrong
Your developer finishes a feature. They SSH into the production server. They run a git pull.
They restart the application. Refresh the browser. Pray.
If something breaks, they SSH back in, check the logs, revert manually, and restart again. Downtime: 20 minutes if they’re fast, hours if they’re not.
This is how a surprising number of teams still ship software. It’s slow, risky, and entirely avoidable.
What CI/CD Actually Means
CI stands for Continuous Integration. Every time a developer pushes code to the repository, automated tests run immediately.
If the tests fail, the team knows within minutes. Not days later when someone notices a bug in production.
CD stands for Continuous Deployment (or Continuous Delivery, depending on how far you go). Code that passes all tests gets automatically deployed to production. No manual steps between “it works” and “it’s live.”
Together, they create a pipeline: code goes in one end, tested and deployed software comes out the other.
The numbers back it up. Organizations with CI/CD see a 33% reduction in time-to-market compared to manual approaches. Change failure rates drop by 50%.
Teams release code twice as fast.
Netflix deploys thousands of changes per day. Etsy went from weekly manual deployments to 50+ per day.
You don’t need to be Netflix. But deploying with confidence beats deploying with crossed fingers.
The Anatomy of a Pipeline
A typical CI/CD pipeline has five stages. Each one catches different problems.
Source stage: a developer pushes code or opens a pull request. This triggers the pipeline automatically.
Build stage: the application gets compiled or bundled. Dependencies get installed. Docker images get built. If the build fails, something basic is broken.
Test stage: automated tests run. Unit tests first (fast, cheap), then integration tests (slower, more thorough). If tests fail, the change broke something.
Deploy to staging: the application goes to a staging environment that mirrors production. This is where QA happens, where stakeholders can preview changes, and where you catch issues that tests missed.
Deploy to production: after staging approval (automatic or manual), the same build artifact goes to production. Not a new build. The exact same one that was tested.
That last point matters. “But it worked in staging” becomes a thing of the past when the same binary goes to both environments.
Setting Up Your First Pipeline
GitHub Actions is the fastest way to start. It’s built into GitHub, free for public repos, and has generous limits for private ones. Your pipeline configuration lives in a YAML file in your repository.
The basic setup takes about 20 minutes. Create a .github/workflows/deploy.yml file. Define the trigger (push to main branch). Add steps for installing dependencies, running tests, building the application, and deploying.
For deployment, start simple. SCP to your server, or SSH and run commands, or push a Docker image and pull it on the server. You can add sophistication later.
The important thing is that it’s automated.
GitLab CI/CD is the other popular choice. Same concept, different syntax. If your code lives on GitLab, use GitLab CI.
What to Test in Your Pipeline
Not everything needs to be tested in CI. But some things absolutely must.
Unit tests: test individual functions and components. These should run in seconds. Aim for the critical business logic first, not 100% coverage.
Integration tests: test that different parts of your system work together. API endpoints return the right data. Database queries work correctly. These take longer but catch more.
Linting and formatting: catch style issues and potential bugs before they get to code review. ESLint, Prettier, or your language’s equivalent.
Security scanning: tools like npm audit or Snyk check your dependencies for known vulnerabilities. Free and takes seconds.
Build verification: does the application actually build? It sounds obvious, but catching build failures before deployment prevents a lot of grief.
Skip the end-to-end browser tests in your initial pipeline. They’re slow, flaky, and not worth the maintenance cost until your pipeline is mature. Add them later if you need them.
Branching Strategy: Keep It Simple
Don’t over-engineer your Git workflow. For most teams, trunk-based development works best.
Developers create short-lived feature branches. They open a pull request when the work is ready. CI runs on the pull request.
If it passes, the code gets merged to main. Main is always deployable.
That’s it. No develop branch. No release branches. No gitflow with its seven-branch dance.
If you need to gate production deployments, add a manual approval step between staging and production. One click to promote, not a branch merge ceremony.
Rollback: Plan for Failure
Things will break. What matters is how fast you recover.
The simplest rollback strategy: deploy the previous version. If your pipeline builds and tags Docker images, rolling back means deploying the previous tag. Two-minute recovery.
Blue-green deployments give you even faster rollback. Run two identical environments. Deploy to the inactive one. Switch traffic over. If something’s wrong, switch back. Zero downtime.
Canary deployments route a small percentage of traffic to the new version first. If error rates spike, pull back before most users are affected. More complex to set up but safer for high-traffic applications.
For most SMB teams starting out, “deploy previous version” is sufficient. Graduate to blue-green or canary when you have the traffic to justify it.
Automated CI/CD is the foundation for everything else in modern engineering. Without it, you can’t do DevOps. You can’t ship fast. You can’t recover from mistakes quickly. Start here.
For the broader DevOps approach without a platform team, our guide covers the full stack. And for how CI/CD fits into a company-wide digital transformation, start with the playbook.
Still deploying manually? Let’s set up a proper pipeline for your team. We’ll assess your current workflow, build the right CI/CD setup, and have you shipping with confidence in a week.
