Dimarts, 10:00 AM. L'equip d'enginyeria de FinPay (nom anonimitzat) es reuneix per al deploy setmanal. 47 commits acumulats des de l'últim deploy del dimarts anterior. 2 hores de finestra de manteniment. Un runbook de 34 passos a Notion. Tres enginyers sènior dedicats exclusivament al procés.
Dijous, 10:00 AM. Segon deploy de la setmana. Aquest cop només 21 commits, però un d'ells trenca producció. Rollback manual. 4 hores de downtime. Clients corporatius (B2B SaaS de gestió de pagaments) sense accés als seus dashboards. 18k € en SLA penalties.
Vuit setmanes després: 15 deploys al dia. Zero downtime. Vulnerabilitats crítiques detectades en CI abans d'arribar a producció. El mateix equip, una arquitectura completament diferent.
Aquest és el cas d'estudi complet de com una fintech Sèrie B (3,2 M€ ARR, 18 enginyers) va transformar el seu procés de delivery implementant un Centre d'Excel·lència DevSecOps en 8 setmanes.
Context: El problema no era tecnològic
Quan FinPay ens va contactar el març de 2024, el diagnòstic inicial semblava clar: "Necessitem CI/CD". Però després de 3 dies d'auditoria tècnica, vam descobrir que el problema era més profund.
Stack existent (pre-transformació):
- Aplicació: Monòlit Node.js + PostgreSQL + Redis
- Infraestructura: AWS EC2 (instàncies gestionades manualment)
- Deploy: Script bash custom executat per SSH
- Testing: Tests unitaris en local, sense CI
- Monitoratge: CloudWatch bàsic + PagerDuty
- Seguretat: Scans manuals de dependències 1x/mes
Els símptomes que reportaven:
- Deploys lents i arriscats: Només dimarts i dijous, 2-4 hores de finestra cadascun
- Rollbacks freqüents: 1 de cada 4 deploys fallava i requeria rollback manual
- Vulnerabilitats en producció: Dependències amb CVEs crítics descobertes després del deploy
- Colls d'ampolla humans: Només 2 enginyers sènior podien fer deploys (knowledge hoarding)
- Lead time altíssim: De commit a producció: 3-7 dies de mitjana
Cost d'oportunitat: Features crítiques endarrerides setmanes perquè "no podem fer més de 2 deploys/setmana". Roadmap paralitzat per procés, no per capacitat de desenvolupament.
La causa arrel (el que vam descobrir a l'auditoria):
El problema no era "falta de CI/CD". Era un sistema de lliurament dissenyat per minimitzar el risc mitjançant control manual, no per minimitzar el risc mitjançant automatització i feedback ràpid.
Símptomes d'un enfocament "gatekeeper" vs "guardrails":
- El deploy requeria aprovació manual del CTO (bottleneck organitzacional)
- Els tests corrien només en local, no hi havia validació automatitzada pre-merge
- La configuració d'infra vivia al cap de 2 enginyers sènior (tribal knowledge)
- El rollback era manual perquè no hi havia versionat de configuració ni infra-as-code
"Sabíem que necessitàvem CI/CD, però cada cop que ho intentàvem implementar, l'equip deia 'no tenim temps, estem apagant focs'. Era un cercle viciós: deploys lents generaven més bugs, més bugs generaven més por a desplegar, més por alentia encara més els deploys."
— CTO de FinPay
La transformació: Framework de 8 setmanes
Vam implementar un Centre d'Excel·lència DevSecOps amb una premissa no negociable: 0 sprints perduts. L'equip havia de seguir lliurant features mentre transformàvem el procés.
Setmana 1-2: Fonaments + Quick Wins (CI bàsic)
Objectiu: Demostrar valor immediat i construir momentum.
Accions:
- GitHub Actions setup: Pipeline bàsic que corre tests a cada PR
- Branch protection: Cap merge sense tests passing + 1 approval
- Docker containerization: App containeritzada per eliminar el "works on my machine"
- Entorn de staging: Rèplica de producció per validar deploys
Resultat Setmana 2:
- ✅ 100% de PRs validats amb tests automàtics
- ✅ 3 bugs crítics detectats en CI que abans arribaven a producció
- ✅ Temps de code review reduït un 40% (tests automàtics = confiança)
- ✅ Equip entusiasmat: "Per primera vegada en mesos no vam tenir un rollback d'emergència"
Setmana 3-4: Continuous Deployment + Infra as Code
Objectiu: Automatitzar el deploy complet a staging i configurar infra reproduïble.
Accions:
- Terraform setup: Tota la infra AWS codificada (VPC, RDS, ECS, ALB, CloudFront)
- ECS Fargate migration: D'EC2 manual a contenidors gestionats
- Auto-deploy a staging: Cada merge a main → deploy automàtic a staging
- Smoke tests post-deploy: Validació automàtica d'endpoints crítics
Resultat Setmana 4:
- ✅ Staging sempre actualitzat amb l'última versió de main
- ✅ Infra 100% reproduïble: entorn nou aixecat en 12 minuts
- ✅ Deploy a staging: de 2 hores manuals a 8 minuts automàtics
- ✅ Zero configuració manual de servidors
Setmana 5-6: Security Shift-Left + Continuous Deployment a Producció
Objectiu: Integrar la seguretat en CI/CD i habilitar deploys diaris a producció.
Accions:
- SAST integrat: SonarQube en CI per detectar vulnerabilitats en codi
- Dependency scanning: Snyk automàtic a cada PR per a dependències vulnerables
- Container scanning: Trivy per escanejar imatges Docker pre-deploy
- Secrets management: AWS Secrets Manager + rotació automàtica
- Blue-green deployment: Deploy a producció amb rollback instantani
- Feature flags: LaunchDarkly per desacoblar deploy de release
Resultat Setmana 6:
- ✅ Primer deploy a producció amb pipeline complet: 12 minuts de commit a live
- ✅ Vulnerabilitats detectades en CI: 9 CVEs critical/high bloquejats pre-merge
- ✅ Rollback provat en staging: 47 segons (vs 1-2 hores abans)
- ✅ Feature flags operatius: deploys sense activar features (risk mitigation)
Setmana 7-8: Observability + On-call Automation + Enablement
Objectiu: Tancar el loop de feedback i escalar el coneixement a tot l'equip.
Accions:
- Datadog APM: Tracing distribuït + mètriques custom de negoci
- Alerting intel·ligent: Alerts basats en SLIs (latency p99, error rate, throughput)
- Incident response automation: Runbooks automatitzats a PagerDuty
- Self-service deploys: Qualsevol developer pot desplegar amb una comanda de Slack
- Internal docs: Playbook a Confluence amb arquitectura, runbooks, troubleshooting
- Enablement sessions: 4 sessions de 90 min per a tot l'equip
Resultat Setmana 8:
- ✅ 100% de l'equip d'enginyeria pot fer deploys (vs 2 persones abans)
- ✅ Mean Time to Detection (MTTD): de ~40 min a <3 min
- ✅ Mean Time to Recovery (MTTR): de ~2 hores a <5 min
- ✅ Documentació completa: 0 tribal knowledge crític
Resultats quantificats: 12 setmanes post-transformació
Tres mesos després del Go-Live del nou procés DevSecOps, vam mesurar l'impacte real:
Velocitat de lliurament (Deployment Frequency):
- Abans: 2 deploys/setmana = ~8 deploys/mes
- Després: 15 deploys/dia de mitjana = ~450 deploys/mes
- Millora: 56x més deploys
Lead Time (commit → producció):
- Abans: 3-7 dies (mitjana 5 dies)
- Després: 12-45 minuts (mitjana 28 minuts)
- Millora: 257x més ràpid
Change Failure Rate (% deploys que fallen):
- Abans: 23% (gairebé 1 de cada 4 deploys requeria rollback)
- Després: 2,1% (1 de cada 48 deploys)
- Millora: 91% de reducció en fallades
Time to Restore (MTTR):
- Abans: 1-4 hores (mitjana 2,3 hores)
- Després: <5 minuts (blue-green rollback automàtic)
- Millora: 27x més ràpid per recuperar
Seguretat (vulnerabilitats en producció):
- Abans: 7 CVEs critical/high descobertes en prod en 3 mesos
- Després: 0 CVEs critical/high en prod (totes bloquejades en CI)
- Millora: 100% de critical/high vulnerabilities previngudes
Costos d'infraestructura:
- Abans: 4.200 €/mes (EC2 over-provisioned + RDS + CloudFront)
- Després: 3.100 €/mes (ECS Fargate auto-scaling + RDS optimitzat)
- Estalvi: 26% de reducció (~13k €/any)
ROI del projecte: Inversió total 28k € (8 setmanes de CoE DevSecOps). Break-even: 4,2 mesos. ROI any 1: 340% considerant l'estalvi d'infra + la reducció de downtime + la productivitat dels developers.
L'impacte qualitatiu (el que no mesuren les mètriques)
Més enllà dels KPIs de DORA, hi va haver canvis culturals i de producte que van transformar el negoci:
1. Canvi de mindset: De "els deploys són arriscats" a "els deploys són rutina"
Abans, cada deploy era un esdeveniment estressant que requeria la coordinació de múltiples persones. Ara, desplegar és tan comú com fer commit. Resultat: els developers experimenten més, iteren més ràpid, aprenen més ràpid.
"Abans planificàvem features pensant 'això ha de quedar perfecte perquè només podem desplegar 2 cops per setmana'. Ara pensem 'despleguem un MVP i ajustem demà si cal'. Això va canviar completament com dissenyem producte."
— Product Manager de FinPay
2. Democratització del coneixement tècnic
Van passar de tenir 2 "deploy guardians" (bottleneck humà) a que tot l'equip d'enginyeria pugui desplegar. Això va eliminar el risc de bus factor i va distribuir la responsabilitat.
3. Recruiting advantage
Al seu job posting actualitzat, ara esmenten: "Full CI/CD with GitHub Actions, IaC with Terraform, blue-green deployments, feature flags, comprehensive observability". Resultat: 3x més applicants sènior en els últims 6 mesos.
4. Velocitat d'experimentació en producte
Amb feature flags i deploys diaris, ara corren A/B tests de features noves en producció amb clients reals. Exemple recent: van provar 3 versions d'un flux d'onboarding en 2 setmanes (abans hauria trigat 2 mesos).
Errors que vam evitar (i tu també hauries d'evitar)
No tot va ser perfecte. Aquests van ser els anti-patterns que vam identificar i corregir:
- Intentar canviar-ho tot alhora
Error inicial: Volien migrar a microserveis + implementar CI/CD + canviar l'stack alhora. Solució: Enfocar-se només en CI/CD primer, mantenir el monòlit. Els microserveis poden venir després si tenen sentit de negoci. - No involucrar els developers en el disseny del pipeline
Si imposes un pipeline des de dalt, ningú no l'adoptarà. Vam fer workshops col·laboratius on l'equip va dissenyar el seu propi workflow ideal, i nosaltres el vam implementar. - Buscar la perfecció abans del primer deploy automàtic
Millor un pipeline "bo" funcionant a la Setmana 2 que un pipeline "perfecte" a la Setmana 8. Iterar sobre alguna cosa que funciona és més fàcil que construir en el buit. - No mesurar abans de començar
Si no mesures l'estat actual (lead time, deploy frequency, MTTR), no pots demostrar la millora. Les baseline metrics són crítiques. - Oblidar la documentació i l'enablement
Una transformació tècnica sense transferència de coneixement és una consultoria que es converteix en dependència. L'objectiu és que l'equip sigui autònom.
És replicable a la teva startup?
Aquest cas és d'una fintech Sèrie B amb 18 enginyers. Però el framework és escalable cap amunt i cap avall:
Si ets més petit (5-10 developers):
- El mateix procés triga 4-6 setmanes en lloc de 8
- Pots començar amb GitHub Actions + Vercel/Railway/Fly.io (sense Terraform/ECS)
- Menys focus en governance, més en quick wins d'automatització
Si ets més gran (30-100 developers):
- El procés triga 10-14 setmanes (més stakeholders, més legacy, més compliance)
- Necessites un platform team dedicat post-transformació
- Més focus en multi-environment strategy, RBAC, audit trails
El no negociable (independent de la mida):
- Automatitzar el testing: Sense tests automàtics, CI/CD és només "Continuous Disaster"
- Infra as Code: Sense IaC, no hi ha reproduïbilitat ni disaster recovery fiable
- Security shift-left: Detectar vulnerabilitats en CI, no en producció
- Observability: Si no mesures, no saps si ha millorat ni quan alguna cosa es trenca
- Enablement de l'equip: La transformació tècnica requereix transformació cultural
El teu equip està en la situació de FinPay el març de 2024?
Si els deploys són esdeveniments estressants en lloc de rutina diària, si les vulnerabilitats es descobreixen en producció en lloc de CI, si només 2 persones poden fer deploys, no estàs sol.
El 73% de startups Sèrie A-B a Espanya tenen processos de delivery similars als de FinPay pre-transformació. No perquè no sàpiguen que DevOps és important, sinó perquè no saben com implementar-lo sense paralitzar lliuraments durant setmanes.
A onext implementem Centres d'Excel·lència DevSecOps específicament per a startups tech. En 6-10 setmanes, transformem el teu procés de delivery de "manual i arriscat" a "automatitzat i fiable".
Sense paralitzar lliuraments. Sense reescriure la teva aplicació. Sense contractar un platform team.
Peça escrita per l'equip tècnic d'onext, consultora espanyola d'IA aplicada. Recull la pràctica de l'equip en transformació d'equips de desenvolupament, cloud, DevSecOps i qualitat: 12 equips transformats i 0 sprints perduts.