CI/CD per a equips petits: no necessites la infraestructura de Netflix

El teu equip desplega a mà. Sense CI/CD, algú es connecta al servidor, fa un pull, executa unes ordres i creua els dits. O potser teniu un script que automatitza part del procés, però ningú no recorda qui ho va escriure ni què fa exactament.

Saps que hauríeu de tenir un pipeline de CI/CD. Hi has llegit. Però cada article que trobes parla de Kubernetes, service mesh, canary deployments i eines amb noms que sonen a missions espacials.

El problema no és que CI/CD sigui complex. És que la indústria ho ha complicat innecessàriament. Per a un petit equip, un bon pipeline es munta en una tarda i canvia la manera de treballar des del primer dia.

Què és CI/CD (sense el soroll)

CI/CD són dues pràctiques que es complementen, però que pots adoptar per separat.

CI (Integració Contínua) significa que cada cop que algú puja codi al repositori, un sistema automatitzat el compila, executa els tests i verifica que tot funciona. Si alguna cosa falla, l'equip se n'assabenta en minuts, no pas en dies.

CD (Desplegament Continu o Lliurament Contínu) significa que aquest codi verificat es desplega automàticament en un entorn (staging, producció o ambdós). Sense intervenció manual. Sense connectar-se a servidors. Sense creuar dits.

La diferència entre Lliurament Contínu i Desplegament Continu és subtil però rellevant. Lliurament continu porta el codi fins a un entorn de staging llest per a producció, però el desplegament final es dispara manualment (un botó, una aprovació). Desplegament Continu el porta directament a producció. Per a equips petits, començar amb Lliurament Contínu sol ser més prudent.

Per què un equip petit ho necessita més que un de gran

Hi ha una idea equivocada que CI/CD és un luxe per a equips grans. En realitat, és al revés. Un equip gran es pot permetre tenir una persona dedicada a desplegar, a investigar per què els tests fallen oa coordinar releases. Un equip petit no.

Quan sou tres o cinc desenvolupadors, cada hora compte. I els desplegaments manuals consumeixen hores de manera invisible.

Desplegar a mà és lent. Segons l'informe DORA State of DevOps , els equips sense automatització triguen entre una hora i un dia a desplegar un canvi. Els equips amb CI/CD ho fan en minuts. Multiplicat per dos o tres desplegaments a la setmana, els comptes són clars.

Desplegar a mà és arriscat. Quan el procés depèn que algú executi els passos correctes a l'ordre correcte, qualsevol oblit o error genera incidents. Un equip petit no té marge per apagar focs que es podien haver evitat.

Desplegar a mà bloqueja lequip. Si només una persona sap desplegar, aquesta persona es converteix en un coll dampolla. Si està de vacances, malalta o simplement ocupada, ningú no desplega. El coneixement de desplegament no pot viure al cap duna sola persona.

CI/CD allibera temps per construir. El temps que el teu equip dedica a desplegar, verificar i apagar focs, és temps que no dedica a construir producte. Un pipeline automatitzat torna aquest temps.

Què muntar primer (i què pot esperar)

Aquí és on la majoria de guies es desvien. Et diuen que necessites tot des del principi: tests unitaris, tests d'integració, tests end-to-end, anàlisi estàtica, escaneig de seguretat, desplegament blue-green, rollback automàtic.

No. Necessites el mínim que funcioni. Després iteres.

Pas 1: Un repositori net amb branques protegides

Si el vostre equip treballa directament sobre main sense pull requests, aquest és el primer problema. Abans d'automatitzar res, estableix un flux bàsic: cada canvi va en una branca, es revisa mitjançant pull request i es mergeja a main quan està llest.

No fa falta un flux de branques complex. Main com a branca de producció i branques de feature és suficient per començar. Git Flow, Trunk Based Development i altres estratègies poden venir després.

Pas 2: Tests que s'executen a cada push

No necessites un 80% de cobertura per començar. Necessites els tests que validen que la teva aplicació arrenca, que les rutes principals funcionen i que la lògica de negoci crítica no està trencada.

Si tens zero tests, comença per tres o cinc que cobreixin els fluxos més importants. A un backend Django, per exemple, un parell de tests sobre les vistes principals i la lògica de negoci crítica ja et donen una xarxa de seguretat real. En una app Flutter, els giny tests dels fluxos clau compleixen la mateixa funció. Un pipeline amb pocs tests bons és infinitament millor que un pipeline sense tests.

L'eina més accessible per a això és GitHub Actions . Si el teu codi és a GitHub, el CI ve inclòs. Un fitxer YAML al vostre repositori i els tests s'executen a cada push. GitLab CI/CD funciona igual si utilitzes GitLab. Tots dos tenen tiers gratuïts més que suficients per a equips petits.

Pas 3: Desplegament automàtic a staging

Quan main té codi que ha passat els tests, un pas automatitzat el desplega en un entorn de staging. No en producció (encara). En un entorn on l'equip pugui verificar que tot funciona abans d'exposar-lo a usuaris.

Si la teva infraestructura és a AWS, serveis com Elastic Beanstalk o ECS permeten desplegaments automàtics des del pipeline. Si utilitzeu un VPS amb bona relació cost/rendiment (Hetzner, per exemple), un script de desplegament que s'executi via SSH des de GitHub Actions o GitLab CI aconsegueix el mateix sense pagar de més. No necessites orquestradors ni serveis managed si el teu projecte no els justifica. L'important és que el desplegament a staging passi sense que ningú es connecti a mà al servidor.

Pas 4: Desplegament a producció amb un botó

No automatitzis el desplegament a producció des del primer dia. Comença amb un pas manual: algú revisa staging, confirma que tot està bé i prem un botó al pipeline per desplegar la producció.

Aquest botó és important. Dóna control sense treure automatització. El 95% del procés és automàtic (build, tests, staging). Només l'últim pas —la decisió d'anar a la producció— és humà. Amb el temps, si la teva pipeline és fiable i els teus tests són sòlids, pots eliminar aquest pas i passar a desplegament continu complet.

El pipeline mínim viable

Perquè quedi concret, això és el que hauria de fer el teu pipeline a cada push a una pull request:

Instal·lar dependències. Executar linter (per mantenir lestil de codi). Executar tests. Si tot passa, marcar la PR com a llista per a review. Si alguna cosa falla, bloquejar el merge.

I quan la PR es mergeja a main:

Executar tests una altra vegada (per si hi ha conflictes del merge). Construir laplicació. Desplegar a staging automàticament. Notificar a l'equip (Slack, email, el que feu servir).

Això es munta a GitHub Actions o GitLab CI en menys dun dia. Per a un projecte Django amb Python, el workflow cap en 40-50 línies de YAML: instal·lar dependències amb pip, executar pytest i desplegar el teu servidor (AWS, un VPS a Hetzner o on el tinguis). Per a una app Flutter, el pipeline inclou flutter analyze, flutter test i la generació del build per a iOS i Android. No necessites cap expert en DevOps. Necessites un desenvolupador amb mitja hora i la documentació oberta.

Errors que cometen els equips petits

Automatitzar massa aviat. Si el teu equip no té tests ni pull requests, muntar un pipeline de desplegament automàtic és construir la casa per la teulada. Primer les bases (repo net, tests bàsics), després l'automatització.

Copiar pipelins de projectes grans. Un pipeline d'una empresa amb 200 enginyers té passos que el teu equip no necessita: escanejats de seguretat complexos, matrius de tests en 15 versions de Python, aprovacions de tres nivells. Copia el concepte, no pas la implementació. El vostre projecte Django necessita un linter, pytest i un desplegament al vostre servidor. No Kubernetes ni un clúster de contenidors que ningú no mantindrà.

No mantingueu els tests. Un test que falla intermitentment i que l'equip ignora és pitjor que no pas tenir test. Si un test és inestable, arregla'l o esborra'l. El pipeline ha de ser fiable: si diu que alguna cosa falla, ha de ser veritat.

Oblidar les notificacions. Un pipeline que falla en silenci no serveix. Configura notificacions perquè l'equip s'assabenti immediatament quan es trenca alguna cosa. Si ningú se n'assabenta, ningú no ho arregla.

Invertir en eines cares. GitHub Actions i GitLab CI/CD tenen plans gratuïts que cobreixen de sobres les necessitats d'un petit equip. No necessites Jenkins, no necessites un servidor de CI dedicat, no necessites eines enterprise. El mateix aplica a la infraestructura: un VPS ben configurat desplega igual de bé que un servei managed a una fracció del cost. Si algun dia necessites escalar, migrar és senzill.

El que canvia quan ho tens

L'efecte d'un bon pipeline de CI/CD en un petit equip és desproporcionat respecte a l'esforç de muntar-lo.

Deixes de tenir por de desplegar. Els divendres a les 17:00 deixen de ser una zona de risc perquè desplegar ja no implica ni downtime ni incertesa. Desplegar es converteix en una cosa que fas diverses vegades al dia sense pensar-ho.

Els errors es detecten abans. Un test que falla a la PR t'estalvia descobrir el problema en producció amb un usuari enfadat al telèfon.

L?equip guanya confiança. Saber que cada canvi passa per un filtre automàtic abans d'arribar a la producció redueix l'ansietat i permet moure's més ràpid.

I potser el més important: deixes de dependre duna persona per desplegar. Qualsevol equip pot portar un canvi a producció seguint el mateix procés, amb les mateixes garanties.

Comença avui, no la setmana que ve

Muntar un pipeline bàsic de CI/CD no és un projecte de dues setmanes. És un dia de feina. Potser dues si mai no has tocat GitHub Actions. El ROI es nota des de la primera setmana.

Si el teu equip té entre 3 i 10 persones i desplegueu a mà, avui és el millor dia per deixar de fer-ho. No pas perquè sigui el que fan les empreses grans. Sinó perquè és el que necessita el teu equip per deixar de perdre temps en coses que una màquina fa millor.