DevOps is the practice of getting software from a developer's keyboard into users' hands quickly, safely, and repeatably — by treating operations (servers, deploys, monitoring) as a software problem rather than a manual chore. If Cartara flagged something DevOps-related in your diff, you likely touched deployment configuration, infrastructure setup, or the pipeline that moves code to production.
What DevOps actually means
The core idea: the people who write software and the people who run it shouldn't be separate teams throwing work over a wall. When the same team owns a change from commit to production and is responsible for it once it's live, they're motivated to make deploys safe, automated, and observable.
In practice, doing DevOps means:
- Automating the path to production (CI/CD)
- Describing infrastructure as code so it's reproducible
- Shipping changes with controlled rollouts
- Watching what happens after deploy (monitoring and observability)
- Improving based on what the data tells you
The goal across all of it: small, frequent, reversible changes beat big, rare, risky ones. A team that deploys 10 times a day has smaller, lower-risk changes than one that deploys monthly. When something breaks, it's easier to find and fix.
The build and ship pipeline
How code gets from a commit to production:
CI/CD — the automated pipeline that builds your code, runs tests, and deploys it. GitHub Actions, Vercel's built-in deployment, and Railway's auto-deploy are all CI/CD. The key is that nothing goes to production manually — the pipeline does it, and it's repeatable. See CICD Basics.
Testing — the safety net under CI/CD. Tests catch regressions before they reach users. Without tests in the pipeline, you're relying on manual verification before every deploy. See Testing and QA.
Deployment strategies — not all deploys are created equal. Rolling deploys, blue-green deployments, and canary releases are techniques for shipping to production without downtime or risk to all users at once. See Deployment Strategies.
Infrastructure and configuration
Infrastructure as Code means describing your servers, databases, and network configuration in files rather than clicking through a web console. When infrastructure is code, it's version-controlled, reviewable, and reproducible. Terraform is the most common tool. See Infrastructure as Code.
Secrets and config management — environment variables, API keys, and database passwords need to live somewhere secure and be injected into your app at runtime. Hardcoding them or committing them to Git is a serious security risk. See Secrets and Config Management.
Containerization — packaging your app and its dependencies into a Docker image so it runs the same way everywhere: your laptop, staging, and production. See Containerisation Basics.
Keeping it running and improving
Monitoring and observability — you can't fix what you don't know is broken. Uptime checks, error tracking (Sentry), and logging are the minimum. See Monitoring and Observability Basics.
SRE and incident management — Site Reliability Engineering gives you a framework for deciding how reliable something needs to be (SLOs), and a calm process for when things break (incident management, blameless postmortems). See SRE and Incident Management.
DORA metrics — four numbers that measure how well a team delivers software, balancing speed against stability. Deployment frequency, lead time, change failure rate, and time to restore. See DORA Metrics.
What You'll See in Your Code
Cartara often flags manual deployment steps or missing automation. A common example is a deployment that requires manual commands instead of being triggered automatically:
# .github/workflows/deploy.yml
# This replaces manual "git pull && npm run build && pm2 restart" on a server
name: Deploy to Production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Deploy
run: vercel deploy --prod --token ${{ secrets.VERCEL_TOKEN }}Missing environment separation — the same code talking to the production database during development:
// Problematic: one database URL used everywhere
const db = new PrismaClient({
datasources: { db: { url: 'postgres://prod-db:5432/app' } }
})
// Better: environment-specific via env vars
const db = new PrismaClient()
// DATABASE_URL set differently in .env.local (dev) vs production environmentReading path for builders
If you're new to this, a practical order to tackle these topics:
- CICD Basics — get automated deploys working first
- From Prototype to Production — the launch checklist
- Monitoring and Observability Basics — know when things break
- Secrets and Config Management — keep credentials out of your code
- Deployment Strategies — ship safely as your app grows