Tired of the endless CI/CD tool debate? A Senior DevOps Lead breaks down real-world choices, from the quick-and-dirty to the platform-perfect, to help you finally ship code without the headache.

So, What Do You *Actually* Use for CI/CD? A Senior Engineer’s Unfiltered Guide.

I still get a cold sweat thinking about it. It was 2 AM on a Saturday, a PagerDuty alert screaming about an auth service being down. The ‘fix’ was a one-line change, but our deployment process was a 15-step wiki page that involved three different people, a manual `git pull` on `prod-api-01`, and a prayer. I was the one SSH’d into the box, my fingers hovering over the enter key after a `service restart`, knowing that if I messed this up, the entire weekend was shot. We fixed it, but that feeling of pure, unadulterated terror is why CI/CD isn’t just a “nice to have.” It’s the wall between you and a 2 AM disaster.

The Real Problem: The Paralysis of Infinite Choice

I was scrolling through that Reddit thread, “What do you guys use for CI/CD?”, and I just had to smile. I saw the usual suspects: Jenkins, GitLab, GitHub Actions, CircleCI, ArgoCD… the list goes on. The junior engineers were asking for the “best” one, and the seniors were giving the classic, infuriating answer: “It depends.”

They’re not wrong, but it’s not helpful. The root cause of this debate isn’t about features; it’s about context. You’re not just choosing a tool. You’re choosing an ecosystem, a workflow, a set of skills your team needs to learn, and a line item on your budget. The sheer number of options creates a paralysis where teams spend more time debating tools than they do shipping code. Let’s fix that.

Stop Arguing, Start Shipping: Three Paths to Sanity

Forget finding the “perfect” tool. Let’s find the *right* tool for *you, right now*. Here are the three paths I see teams take, from my experience in the trenches.

1. The Pragmatist’s Path: Use What’s Already There

This is my go-to advice for any team that’s stuck. Where does your code live? If it’s on GitHub, start with GitHub Actions. If it’s on GitLab, use GitLab CI. Don’t overthink it. The friction of adopting a new, separate platform is often a project killer. Using the integrated tool is the path of least resistance, and that’s a feature, not a bug.

Is it the most powerful? Maybe not. Will you eventually hit a wall? Perhaps. But you’ll go from zero to a working pipeline in an afternoon. That’s a massive win.

A basic GitHub Actions workflow to build and push a Docker image is ridiculously simple. You can get this running in minutes:

name: Build and Push Docker Image

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Login to Docker Hub
      uses: docker/login-action@v2
      with:
        username: ${{ secrets.DOCKERHUB_USERNAME }}
        password: ${{ secrets.DOCKERHUB_TOKEN }}

    - name: Build and push
      uses: docker/build-push-action@v4
      with:
        context: .
        push: true
        tags: yourusername/your-app:latest

Pro Tip: The best CI/CD tool is the one your team will actually use. Reducing friction is more important than having a thousand features you’ll never touch. Start with what’s integrated.

2. The Architect’s Path: Choose Your Platform Intentionally

Okay, so you’ve outgrown the simple approach. You have complex needs: Kubernetes-native deployments, orchestrated multi-environment rollouts, strict security scanning gates, or a team dedicated to internal platforms. Now it’s time to put on your architect hat and make a deliberate choice. This means you stop asking “what’s best?” and start asking “what do we need?”

• Do you need to self-host for compliance or cost reasons? (Look at Jenkins, or self-hosted GitLab/Gitea).
• Are you all-in on Kubernetes? (ArgoCD or Flux should be your first stop).
• Is your team mostly developers who want a clean, YAML-based SaaS experience? (CircleCI, TravisCI).
• Are you a Microsoft shop? (Azure DevOps is a surprisingly powerful and integrated choice).

I put together a quick, opinionated cheat sheet to frame this decision:

3. The Minimalist’s Path: The “Bash and a Dream” Approach

Sometimes, all the big platforms are overkill. I’m talking about a small personal project, an internal tool, or a startup that needs to move at lightning speed. In these cases, the “nuclear option” is to blow up the idea of a formal platform entirely.

This is the hacky-but-effective solution: a simple web server listening for a webhook from GitHub, which then executes a shell script. It’s beautiful in its simplicity.

Your `deploy.sh` script on `staging-web-app-01` might look like this:

#!/bin/bash
set -e # Exit immediately if a command exits with a non-zero status.

echo "--- Deploying latest changes from main branch ---"

cd /var/www/my-app
git pull origin main

echo "--- Installing dependencies ---"
npm install --production

echo "--- Restarting application service ---"
pm2 restart my-app

echo "--- Deployment complete! ---"

Is this robust? No. Does it have a UI? No. Can it get you into trouble? Absolutely. But for a team of one or two, it can be a perfectly valid way to automate deployments without the cognitive overhead of a full CI/CD system.

Warning: This path is paved with peril. You are now responsible for the security, logging, and reliability of your “CI/CD server.” Only walk this path if you understand the risks and are willing to maintain it yourself.

My Final Take: The Tool is Not the Goal

At the end of the day, CI/CD is about one thing: delivering value to users faster and more safely. The tool is just a means to an end. Don’t let the search for the perfect tool stop you from building a good-enough process. Pick a path, get something running, and improve it over time. The team that ships is the team that wins—not the team with the most elegant YAML file.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions