Integració i entrega contínues (CI/CD)

CI (integració contínua) és comprovar de manera automàtica cada canvi abans d'integrar-lo. CD (entrega o desplegament continus) és portar aquest canvi a un entorn real sense passos manuals. La majoria d'equips guanya més amb una bona CI que amb qualsevol altra inversió tècnica del mateix cost.

Què comprova la CI, i en quin ordre

1. El més ràpid primer: format i *lint*. Falla en segons i evita soroll a la revisió.
2. Compilació / *type-check*: si no compila, res més importa.
3. Tests unitaris: el gruix de la confiança, haurien de trigar pocs minuts.
4. Tests d'integració i *end-to-end*: més lents i més fràgils; van al final i en paral·lel.
5. Build de l'artefacte de producció: si es prerenderitza o empaqueta, que falli aquí i no al servidor.

Els temps importen més del que sembla

Si el pipeline triga 25 minuts, la gent deixa d'esperar-lo: fusiona abans que acabi, acumula canvis i perd la relació causa-efecte entre un *commit* i la seva fallada. L'objectiu raonable és tenir una resposta de CI en menys de deu minuts. S'aconsegueix amb cau de dependències, paral·lelització i no repetir feina entre etapes.

Gates abans de producció

Entre «la CI passa» i «és a producció» convé posar comprovacions que no són codi: revisió aprovada, migracions de base de dades revisades a part, i una manera de tornar enrere en un minut. El desplegament hauria de ser avorrit; si genera adrenalina, falta automatització.

• Desplegament reproduïble: el mateix artefacte que s'ha provat és el que es publica.
• Tornada enrere ràpida: rellançar la versió anterior no pot dependre de reconstruir res.
• Salut després del desplegament: una comprovació automàtica que el servei respon abans de donar per bona la publicació.

Entorns

Com a mínim, un entorn d'integració que s'assembli a producció (mateixos serveis, dades anonimitzades) on provar abans de publicar. Molts equips s'estalvien incidències només per tenir aquest entorn i fer-lo servir de debò.