• Cuprins
• Drama reală: CI/CD gone wrong
• De ce contează CI/CD în 2025?
• Cum funcționează? Algoritmi, structură, setup rapid
• Cazuri de utilizare & beneficii
• Setup rapid: Ghid pas cu pas pentru fiecare
• Mini Glosar: Real-Talk Definitions
• Exemple reale, pozitive și negative (plus comparație comică)
• Greșeli de începători, mituri și alternative
• Flowchart: Care e potrivit pentru tine?
• Statistici, fun facts & hack-uri neobișnuite
• Scripturi și automatizări cool
• Scurtă poveste de admin
• Concluzie & recomandări

Drama reală: CI/CD gone wrong

Imaginează-ți: ești vineri, ora 16:30. Ai pus un patch urgent pe repo, ai dat push, și… stai liniștit că totul merge, nu? Dar build-ul pică, testele nu rulează, iar colegii te sună pe Discord/Teams/Telegram: „De ce nu merge staging-ul?!” Ai fi vrut să ai un sistem CI/CD pe bune, care să-ți facă munca mai ușoară, nu să-ți dea bătăi de cap. Să nu mai scrii scripturi bash făcute pe genunchi, să nu mai rulezi deploy manual la 2 noaptea. Ești acolo? Da, cu toții am fost.

De ce contează CI/CD în 2025?

• Automatizare totală: Build, test, deploy, rollback, totul fără mâini și fără stres.
• Zero downtime: Cu pipeline-uri bine făcute, deploy-ul devine invizibil pentru utilizatori.
• Time to market: Feature-urile ajung mai repede la clienți, fără bug-uri ascunse.
• Siguranță: Teste automate, scanări de securitate, validări de config – toate integrate în pipeline.
• Fără „merge hell”: Fiecare commit trece prin același filtru, pe orice branch.
• Setup rapid: Azi, poți avea un pipeline funcțional în 30 de minute, chiar și pe un VPS sau server dedicat low-cost.

În 2025, CI/CD nu mai e doar pentru mega proiecte open-source. E pentru oricine vrea să automatizeze, să scaleze și să nu se mai roage să nu crape ceva la deploy.

Cum funcționează? Algoritmi, structură, setup rapid

Ce înseamnă CI/CD?

• CI = Continuous Integration: Fiecare modificare de cod e integrată automat, testată și validată.
• CD = Continuous Delivery/Deployment: Codul ajunge automat pe un environment (staging/prod) după ce trece testele.

Structura generală

1. Trigger: Un eveniment (push, merge, tag, PR) pornește pipeline-ul.
2. Pipeline: O succesiune de job-uri (build, test, deploy, lint, scan).
3. Runners/Workers: Mașini (fizice, VM, containerizate) care execută job-urile.
4. Artefacte: Output-uri salvate (binar, docker image, loguri, etc).
5. Notificări: Slack/email/webhook dacă ceva pică sau merge.

Setup rapid: ce trebuie?

• Un repo (GitHub, GitLab, self-hosted Git, etc)
• Un fișier de config pipeline (YAML, TOML, etc)
• Un runner (cloud sau self-hosted pe VPS/server dedicat)
• Permisiuni de deploy (ssh key, token, etc)

Cazuri de utilizare & beneficii

• Deploy automat pe Docker, Kubernetes, bare-metal sau server dedicat
• Testare automată pe fiecare push (unit, integration, end2end)
• Build de imagini Docker și push în registry
• Scanare automată de securitate (SAST/DAST)
• Generare de artefacte (APK, deb, exe, etc)
• Automatizare de backup sau roll-back la fail

Practic, orice task repetitiv pe care nu vrei să-l faci manual poate fi CI/CD-uit!

Setup rapid: Ghid pas cu pas pentru fiecare

GitHub Actions

1. Mergi în repo-ul tău de GitHub
2. Click pe tab-ul Actions
3. Alege un workflow template sau click pe „set up a workflow yourself”
4. Adaugă un fișier .github/workflows/ci.yml cu conținut ca mai jos:

name: CI/CD Demo

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: echo "Build-ul merge!"
      - name: Deploy
        run: echo "Deploy automat pe server"

5. Salvează și dă push. Ai deja CI/CD basic!

Vrei self-hosted runner? Rulezi pe un VPS și ai nevoie de control? Instalezi un runner cu:

# Pe serverul tău (Linux)
curl -O -L https://github.com/actions/runner/releases/download/v2.310.2/actions-runner-linux-x64-2.310.2.tar.gz
tar xzf ./actions-runner-linux-x64-2.310.2.tar.gz
./config.sh --url https://github.com/ORG/REPO --token TOKENUL_TAU
./run.sh

GitLab CI

1. În repo-ul GitLab, adaugă un fișier .gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Build ok!"

test-job:
  stage: test
  script:
    - echo "Testele rulează!"

deploy-job:
  stage: deploy
  script:
    - echo "Deploy pe VPS"

2. Merge direct cu shared runners de la GitLab, sau poți instala runner pe un VPS cu:

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt-get install gitlab-runner
sudo gitlab-runner register

Urmărești instrucțiunile, alegi executorul (shell, docker, ssh, etc) și gata!

Drone CI

1. Drone e pentru cei care vor full control și self-hosting, cu YAML simplu și integrare bună cu Docker.
2. Rulezi rapid pe VPS/server dedicat:

# docker-compose.yml
version: '3'

services:
  drone-server:
    image: drone/drone:2
    ports:
      - 8080:80
    volumes:
      - ./data:/data
    environment:
      - DRONE_GITEA_SERVER=https://git.instance.tld
      - DRONE_RPC_SECRET=supersecrets
      # configuri pentru GitHub/GitLab dacă e cazul

  drone-runner:
    image: drone/drone-runner-docker:1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - DRONE_RPC_HOST=drone-server
      - DRONE_RPC_SECRET=supersecrets

Pipeline YAML în repo:

kind: pipeline
type: docker
name: default

steps:
  - name: build
    image: node:20
    commands:
      - echo "Build pe Drone!"

Mini Glosar: Real-Talk Definitions

• Runner: Un worker (VM, container sau server) care execută job-urile de CI/CD.
• Pipeline: „Rețeta” de build/test/deploy, scrisă de obicei în YAML.
• Job: O sarcină individuală (ex: build, test, deploy, lint).
• Artefact: Ceva ce iese din build (binar, docker image, log, etc).
• Trigger: Eveniment care pornește pipeline-ul (push, PR, tag).
• Self-hosted: Rulezi tu totul, pe serverul tău, nu pe cloud-ul cuiva.

Exemple reale, pozitive și negative (plus comparație comică)

Comparație comică: Supereroii CI/CD

• GitHub Actions = Iron Man: Elegant, puternic, cu totul integrat, dar dependent de „armura” GitHub. Ușor de folosit, dar dacă vrei control total, trebuie să-ți construiești propriul laborator (self-hosted runner).
• GitLab CI = Batman: Gadgeturi peste gadgeturi, merge și pe cloud și pe serverul tău. Poți face aproape orice, dar trebuie să știi să configurezi totul. E geeky și ultra-flexibil.
• Drone = Deadpool: Fără reguli, self-hosted, rapid, nebun, dar cu o documentație mai „hipster”. Vrei control și să nu depinzi de nimeni? Drone e pentru hackeri adevărați.

Exemple pozitive

• Startup care face deploy pe staging la fiecare PR cu GitHub Actions – zero downtime, feedback rapid, clienți fericiți.
• Companie mică de outsourcing care folosește GitLab CI self-hosted pe un server dedicat – costuri mici, control complet, integrare cu Jira și Slack.
• Proiect open-source cu Drone pe VPS – build rapid, costuri minime, pipeline-uri creative cu Docker și bash.

Exemple negative

• Repo privat pe GitHub cu workflow prea complicat: build-ul durează 40 de minute, nu mai știe nimeni ce face fiecare job.
• GitLab Runner pe un VPS subdimensionat – pipeline-urile pică la fiecare build mai mare.
• Drone CI fără backup la config: un update stricat = haos total, trebuie refăcut totul din memorie.

Greșeli de începători, mituri și alternative

• Mit: „CI/CD e doar pentru proiecte mari” – FALS, orice repo are de câștigat de la automatizare.
• Mit: „E greu de setat” – FALS, poți avea pipeline basic în 5-10 minute.
• Mit: „Trebuie să plătești mereu” – FALS, toate au variante gratuite sau self-hosted.
• Greșeli: Nu pui cache la build-uri, nu folosești artefacte, lași token-uri în YAML, nu securizezi runnerii.

Alternative: Jenkins (bătrân, dar încă folosit), CircleCI, Travis CI, Woodpecker CI, Buildkite etc. Dar pentru majoritatea, GitHub Actions, GitLab CI și Drone sunt best-in-class în 2025.

Flowchart: Care e potrivit pentru tine?

Ai deja repo pe GitHub? 
    ⬇️
 DA —> Vrei să fii rapid, fără bătăi de cap? 
      ⬇️
    DA —> GitHub Actions
    NU —> Vrei self-hosted? 
           ⬇️
         DA —> GitHub Actions cu runner pe VPS
         NU —> GitHub Actions hosted

NU —> Ai repo pe GitLab sau vrei control total?
    ⬇️
  DA —> GitLab CI (self-hosted sau cloud)
  NU —> Vrei să hack-uiești, să rulezi totul singur și să nu depinzi de nimeni?
         ⬇️
       DA —> Drone CI
       NU —> Poate Jenkins, CircleCI, Travis...

Statistici, fun facts & hack-uri neobișnuite

• În 2024, peste 82% dintre proiectele open-source cu peste 1000 stars folosesc CI/CD (sursa: GitHub State of the Octoverse).
• GitLab CI e preferatul pentru self-hosted, mai ales în Europa, pentru GDPR și privacy.
• Drone CI e campion la pipeline-uri ultra-rapide pentru proiecte mici și medii.
• Poți folosi GitHub Actions ca orchestrator pentru deploy pe servere dedicate cu simple comenzi SSH!
• Pipeline-ul tău poate trimite meme pe Slack dacă build-ul pică 😁

Scripturi și automatizări cool

Deploy automat pe VPS cu GitHub Actions:

- name: Deploy pe VPS
  run: ssh -o StrictHostKeyChecking=no user@ip_vps "cd /app && git pull && docker-compose up -d"
  env:
    SSH_PRIVATE_KEY: ${{ secrets.SSH_KEY }}

Testare automată și deploy pe Docker cu Drone:

steps:
  - name: test
    image: python:3.12
    commands:
      - pytest

  - name: build-image
    image: plugins/docker
    settings:
      repo: registry.tld/proiectul-tau/app
      tags: latest

Scurtă poveste de admin

Era odată un sysadmin (îl chema Vlad) care făcea deploy manual la 10 proiecte. Într-o dimineață de luni, după un weekend prelungit, uită să dea restart la un container după update. Prod-ul pică, clienții sună. Vlad descoperă GitHub Actions, face un workflow care să facă deploy și restart automat la fiecare push. De atunci, luni dimineața bea cafeaua liniștit, iar build-urile îi trimit notificări pe Telegram dacă ceva nu merge. Morală: CI/CD îți salvează nervii și reputația.

Concluzie & recomandări

Indiferent ce alegi, important e să începi să automatizezi cât mai repede. În 2025, CI/CD nu mai e un moft, ci un skill de bază. GitHub Actions e perfect pentru workflow-uri rapide și integrare cu ecosistemul GitHub. GitLab CI e pentru control total, self-hosting și integrare cu tot ce vrei. Drone e pentru hackeri și sysadmini care vor să aibă totul sub cheie pe serverul lor.

Nu uita: dacă vrei să-ți pornești rapid un pipeline self-hosted, poți comanda un VPS sau server dedicat și ești la două comenzi distanță de CI/CD-ul tău personal.

Automatizează tot ce se poate, salvează timp și nervi, și nu mai fi „sysadminul de serviciu” la 2 noaptea!

Linkuri utile (oficiale):
GitHub Actions Docs
GitLab CI/CD Docs
Drone CI Docs