Què és CI/CD? Integració i entrega contínues explicades fàcilment

CI/CD és una manera d'enviar programari en què cada canvi de codi es compila, es prova automàticament i —si ho supera— es prepara per publicar o es publica. CI (integració contínua) vol dir que els canvis es fusionen sovint i s'interroguen amb proves automatitzades cada vegada. CD (lliurament o desplegament contínu) vol dir que els canvis que passen es empaqueten i s'envien cap als usuaris amb poca o cap feina manual.

La idea és simple: detectar els errors minuts després de cometre'ls, no setmanes després quan un client els troba.

Per què importa CI/CD quan construeixes amb IA

Els constructors amb IA fan canvis de codi molt ràpidament. Una sola instrucció pot tocar deu fitxers. Aquesta velocitat és genial fins que un canvi a la pàgina de pagament trenca discretament la pàgina de login i ningú no se n'adona fins que un usuari t'escriu un correu.

CI/CD és la xarxa de seguretat per a exactament aquest cas. En lloc de confiar que cada canvi està bé, una pipeline executa les mateixes comprovacions cada vegada:

• L'aplicació encara es compila sense errors?
• Les proves automatitzades continuen passant?
• El codi segueix les normes del projecte (tipus, format, controls de seguretat)?

Si alguna comprovació falla, el canvi s'atura abans d'arribar als usuaris. Com més ràpidament canvia el teu codi, més valor té una comprovació que mai no es cansa ni salta un pas.

Una analogia del dia a dia

Pensa en una fleca que ven pa als comerços cada matí.

• Sense CI/CD, cada fornaler treballa uns dies en els seus propis retocs de recepta durant una setmana, i després tots combinen els canvis el divendres a la nit i esperen que el pa encara pugi. Quan no pugi, ningú no sap de qui era el canvi que ho ha causat.
• Amb CI, cada petit canvi de recepta es cou a l'instant en una coca de prova i es revisa: gust, pes, forma. Un mal canvi es detecta el mateix dia, i saps exactament quin era.
• Amb CD, les coques que superen la inspecció van directament a la furgoneta de repartiment, empaquetades i etiquetades sempre de la mateixa manera, en lloc que algú les empaqueti a mà a les cinc del matí.

La inspecció no fa els fornalers millors. Fa que els seus errors siguin barats.

Com funciona una pipeline de CI/CD

Una pipeline és una llista de passos que un servei de CI/CD executa automàticament quan passa alguna cosa, normalment quan algú puja codi a un repositori com GitHub. Una pipeline típica es veu així:

Cada pas s'executa en una màquina neta, no en l'ordinador de algú, de manera que «a la meva màquina funciona» deixa de ser una excusa. Si un pas falla, la pipeline s'atura i avisa qui ha fet el canvi.

Els passos es defineixen en un fitxer de configuració que viu amb el codi. A GitHub Actions, per exemple, és un fitxer YAML a la carpeta .github/workflows del repositori.

Lliurament contínu vs desplegament contínu

La «CD» és ambigua, i la gent la fa servir de les dues maneres:

El desplegament contínu només funciona bé si les proves són bones. Si les teves proves no cobreixen el pagament, el desplegament contínu publicarà amb molt de gust un pagament trencat.

Un exemple pas a pas: una aplicació de reserves amb una pipeline

Suposem que tens una aplicació de reserves per a una perruqueria, amb el codi en un repositori de GitHub. Demanes a un constructor amb IA que «afegeixi un 10% de descompte per als clients que vénen per primera vegada».

1. El canvi es puja a una branca nova i s'obre una pull request.
2. La pipeline comença. Instal·la paquets i compila l'aplicació: això passa.
3. Executa les proves. Una prova, «un client que torna paga preu complet», falla: el descompte s'està aplicant a tothom.
4. La pull request mostra una creu vermella. El canvi no es pot fusionar.
5. Demanes a la IA que ho arregli. Puja una correcció; la pipeline torna a executar-se i tot passa.
6. El canvi es fusiona. La pipeline el desplega a un entorn de staging, on proves una reserva de prova.
7. L'aprovés i es desplega a producció.

Sense la pipeline, el pas 3 hauria passat a les butxaques dels teus clients.

Termes clau

Idees errònies habituals

• «CI/CD vol dir que la meva aplicació està provada». Una pipeline només executa les proves que tens. Si no n'hi ha, CI només demostra que l'aplicació es compila, res més. Demana a la teva IA que escrigui proves per als fluxos més importants.
• «CI/CD només és per a grans empreses». Eines allotjades com GitHub Actions es configuren amb un fitxer curt, i els petits equips les fan servir contínuament. Són les proves, no les eines, les que costen esforç.
• «El desplegament automàtic vol dir que ningú no comprova res». Les bones pipelines afegeixen comprovacions, no les treuen. Molts equips mantenen un pas d'aprovació humana abans de producció.
• «Si la pipeline està verda, l'aplicació funciona». Vol dir que les comprovacions automàtiques han passat. Igualment hauries de provar el canvi tu mateix, idealment en una vista prèvia o a staging.
• «CI/CD substitueix les còpies de seguretat». No. Una migració de base de dades dolenta que passa les proves pot malmetre dades reals. Mantén còpies de seguretat i una manera de revertir.

Què demanar al teu constructor d'IA

• «Escriu proves automatitzades per al registre, el login i el pagament, i mostra'm com executar-les.»
• «Configura un workflow de GitHub Actions que instal·li les dependències, compili l'aplicació i executi les proves a cada pull request.»
• «Afegeix una comprovació de tipus i un linter a la pipeline, i fes que falli si hi ha errors.»
• «Explica en català senzill què fa cada pas de la pipeline.»
• «Què passa si un desplegament falla a mig camí? Com reverteixo?»
• «Comprova que no hi hagi secrets escrits al repositori ni impresos als registres de la pipeline.»

Si la teva aplicació fa servir claus d'API, la pipeline també les necessita, guardades com a secrets xifrats a l'eina de CI, mai al fitxer de configuració. Consulta variables d'entorn i secrets.

CI/CD i Mythex

Mythex no executa una pipeline de CI per a tu, però cobreix algunes de les mateixes necessitats a la seva manera:

• Punts de control. Després de cada torn exitós de l'agent, Mythex desa un punt de control de git, i Tornar a aquest punt reverteix el projecte si un canvi ha sortit malament. Consulta Xat.
• App Testing. Escriu /test i l'agent fa clic per la teva vista prèvia en directe com ho faria un usuari i informa dels fluxos trencats: útil abans de cada publicació. Consulta App Testing.
• La publicació és un pas deliberat. Els canvis apareixen primer a la vista prèvia privada; la teva aplicació pública només s'actualitza quan tornes a publicar: més a prop del lliurament contínu que del desplegament contínu.
• Sincronització amb GitHub (Pro). Sincronitza el projecte amb un repositori de GitHub i pots afegir els teus propis workflows de GitHub Actions per executar proves a cada push. Consulta GitHub i exportació.

Per a una llista de comprovació del que cal provar a mà abans de sortir en directe, consulta com provar la teva aplicació abans del llançament, i per treballar amb control de versions, com fer servir Git amb una aplicació construïda amb IA.

Preguntes