CI/CD para startups: envíe más rápido sin romper cosas

Las startups que realizan envíos semanales superan a las que realizan envíos mensuales. CI/CD es la forma de realizar envíos semanales sin implementar errores. Es la diferencia entre un equipo que se mueve rápido con confianza y un equipo que se mueve rápido y interrumpe la producción cada dos viernes.

Si está ejecutando una startup con entre 2 y 10 ingenieros y todavía está implementando mediante SSH en un servidor o haciendo clic en "fusionar" y orando, esta guía lo guiará a través de la configuración mínima de CI/CD que necesita. La configuración lleva una tarde, cuesta $0 al mes en los niveles gratuitos y se amortiza la primera vez que detecta un error antes que los usuarios.

Qué significa CI/CD en inglés sencillo

Integración Continua (CI)significa que cada cambio de código se prueba automáticamente. Cuando un desarrollador abre una solicitud de extracción, un servidor ejecuta su linter, el verificador de tipos y el conjunto de pruebas con el nuevo código. Si algo falla, el RP recibe una X roja y nadie lo fusiona hasta que se solucione el problema.

Despliegue continuo (CD)significa que cada prueba aprobada se implementa automáticamente. Cuando el código se fusiona con su rama principal, el sistema lo crea, lo envía a la etapa de preparación y lo deja disponible para su revisión. Las implementaciones de producción se realizan con un solo clic o, si confía en su conjunto de pruebas, de forma automática.

Eso es todo. CI detecta errores antes de que lleguen a su sucursal principal. CD envía código verificado a sus usuarios sin intervención manual. Juntos, reemplazan la conversación "funciona en mi máquina" por "pasó el proceso".

Por qué las startups se lo saltan (y por qué les cuesta más adelante)

El manual implementa el trabajo de 2 ingenieros. Una persona escribe el código, la otra lo revisa, alguien ejecuta git pull en el servidor y la función está activa. Se siente rápido porque el ciclo de retroalimentación es corto.

Se rompen en 5. Con cinco ingenieros impulsando el código, se obtienen conflictos de fusión, interacciones no probadas entre funciones e implementaciones que ocurren en momentos aleatorios. Alguien se fusiona mientras otro está en mitad de la implementación. El servidor tiene cambios no confirmados de una revisión del martes pasado. Nadie está seguro de qué versión se está ejecutando en producción.

Cuando tienes 10 ingenieros, las implementaciones manuales causan2-3 incidentes de producción por mes. Cada incidente cuesta entre 2 y 4 horas de tiempo de ingeniería para diagnosticarlo y solucionarlo. Eso significa que se pierden entre 4 y 12 horas de tiempo de ingeniería senior cada mes; tiempo que estás pagando en salario pero sin obtener valor de producto.

Las matemáticas son sencillas. Un ingeniero senior cuesta entre 75 y 150 dólares la hora. Doce horas de respuesta a incidentes por mes cuestan entre 900 y 1.800 dólares. La configuración de CI/CD lleva una tarde y cuesta $0 al mes en los niveles gratuitos. Recuperas el tiempo de configuración en tu primer mes.

El canal mínimo viable de CI/CD

No necesitas un proceso de 45 minutos con 200 pasos. Necesita cinco controles que detecten el 90% de los errores antes de que lleguen a producción.

1. Pelusa en cada PR

Linting detecta problemas de estilo, variables no utilizadas y errores comunes. ESLint con una configuración estándar (como el ajuste preestablecido de Airbnb o Next.js) tarda entre 5 y 15 segundos en ejecutarse y detecta problemas que de otro modo aparecerían en la revisión del código. Esto libera a los revisores para que puedan centrarse en la lógica y la arquitectura en lugar de formatear los argumentos.

2. Escriba la verificación en cada PR

Si está utilizando TypeScript (y debería hacerlo), ejecute tsc --noEmit en cada solicitud de extracción. Esto detecta errores tipográficos que su editor podría pasar por alto; especialmente errores en archivos que no cambiaste directamente pero que dependen del código que modificaste. Un error de tipo detectado en CI cuesta 2 minutos para solucionarlo. El mismo error detectado en producción cuesta 2 horas.

3. Ejecute pruebas en cada RP

Las pruebas automatizadas verifican que su código haga lo que se supone que debe hacer. Un conjunto de pruebas con un buen alcance se ejecuta en 30 a 90 segundos y detecta errores lógicos que no se detectan en la verificación de tipos y el linting. No necesitas una cobertura del 100%. Necesita pruebas de las rutas de código que manejan dinero, datos de usuario y reglas comerciales básicas.

4. Implementación automática para la puesta en escena en combinación con la principal

Cuando un PR pasa todas las comprobaciones y se fusiona, la canalización crea la aplicación y la implementa en un entorno de prueba. Esto le brinda a su equipo una URL activa donde los gerentes de producto, diseñadores y clientes pueden revisar los cambios antes de que entren en producción. No más "¿puedes implementar la preparación para que pueda probar esto?" mensajes en Slack.

5. Implementación en producción con un solo clic

Las implementaciones de producción deberían requerir una única acción deliberada: hacer clic en un botón, ejecutar un comando o fusionarse con una rama de producción. La palabra clave esDeliberada. Quiere que un humano decida "sí, esto está listo para los usuarios", pero no quiere que ese humano ejecute 15 pasos manuales para que esto suceda.

Herramientas y costos

No necesita gastar dinero para conseguir un canal de CI/CD que funcione. Cada herramienta de esta lista tiene un nivel gratuito que cubre las empresas emergentes en etapa inicial.

Acciones de GitHubEs gratuito para repositorios públicos e incluye 2000 minutos por mes para repositorios privados. Eso es suficiente para un equipo de 5 a 8 ingenieros que realizan entre 20 y 30 relaciones públicas por semana. Los pasos de pelusa, verificación de tipos y prueba se ejecutan como un flujo de trabajo que se activa en cada solicitud de extracción.

Vercelse implementa automáticamente en cada envío, le brinda URL de vista previa para cada PR y maneja los entornos de preparación y producción listos para usar. El nivel gratuito cubre la mayoría de las empresas emergentes hasta que alcanzan un tráfico significativo. Si está compilando con Next.js, Astro o cualquier marco de interfaz, Vercel es el camino más rápido hacia el CD.

Ferrocarrilmaneja servicios backend, bases de datos y trabajadores en segundo plano con implementaciones automáticas desde GitHub. El precio comienza en $5/mes con facturación basada en el uso después de eso. Es una buena opción para aplicaciones full-stack que necesitan más que alojamiento estático.

Fly.ioImplementa contenedores Docker en servidores cercanos a sus usuarios. Es una buena opción para API y servicios que necesitan baja latencia en todas las regiones. El nivel gratuito incluye 3 máquinas virtuales compartidas y 160 GB de transferencia saliente.

Qué probar y qué omitir

Probar todo hace que su proceso sea lento. No probar nada no te proporciona ninguna red de seguridad. La respuesta correcta se encuentra en el medio.

Pon a prueba tu lógica empresarial.Si su aplicación calcula precios, valida las entradas del usuario, procesa pagos o aplica reglas de descuento, escriba pruebas para esas funciones. Estas son las rutas de código donde los errores cuestan dinero.

Pruebe sus puntos finales API.Envíe una solicitud, verifique el estado y el cuerpo de la respuesta. Esto detecta errores de enrutamiento, errores de middleware y problemas de serialización que las pruebas unitarias pasan por alto.

Omita la prueba de píxeles de la interfaz de usuario.No pruebes si un botón está a 16 píxeles de la parte superior de su contenedor. Esas pruebas se interrumpen cada vez que cambia su diseño y no detecta ningún error real.

Omita las partes internas del marco.No pruebes si React se vuelve a renderizar cuando cambia el estado. El equipo de React ya lo probó. Pruebe lo que hace su código con la salida renderizada.

La escalera de confianza en el despliegue

Cada paso en su proceso agrega una capa de confianza de que el código es seguro de implementar. Piense en ello como una escalera donde cada peldaño detecta una categoría diferente de error.

Hilasdetecta problemas de formato y errores comunes.Comprobación de tipodetecta formas de datos no coincidentes y errores de referencia nula.Pruebas unitariasdetectar la lógica empresarial rota.Pruebas de integracióndetectar interacciones rotas entre componentes y servicios.Vista previa de la puesta en escenadetecta regresiones visuales y problemas de UX que las pruebas automatizadas pasan por alto.Producciónes el paso final, donde los usuarios reales interactúan con el código verificado.

La mayoría de las nuevas empresas necesitan los primeros cinco peldaños. Puede omitir las pruebas de integración desde el principio y agregarlas cuando su sistema se vuelva lo suficientemente complejo como para justificarlas. Pero la pelusa, los tipos, las pruebas unitarias y las vistas previas de preparación no son negociables desde el primer día.

Las implementaciones de vista previa cambian la forma en que los equipos revisan el código

Cada PR obtiene una URL activa. No es una captura de pantalla en un hilo de Slack. No es una grabación de pantalla. Una versión interactiva y en vivo de su aplicación con los cambios propuestos ejecutándose en un servidor real.

Los gerentes de producto hacen clic en la función y dejan comentarios sobre las relaciones públicas. Los diseñadores comprueban el espaciado y la tipografía en su propia pantalla. Los clientes ven el progreso en tiempo real sin esperar una llamada de demostración. Esto acorta los ciclos de retroalimentación de días a horas.

Vercel y Netlify hacen esto de inmediato. Cada envío a una rama de relaciones públicas genera una URL de vista previa única que se actualiza automáticamente cuando envía nuevas confirmaciones. No se necesita configuración más allá de conectar su repositorio de GitHub.

En Savi, las implementaciones de vista previa han eliminado la conversación "se veía diferente en mi máquina". Las partes interesadas revisan las funciones en el mismo entorno donde finalmente se ejecutará el código. Si funciona en la URL de vista previa, funciona en producción.

Errores comunes que ralentizan a los equipos

Probando todo.Un proceso de 25 minutos acaba con la velocidad del desarrollador. Los ingenieros evitan abrir relaciones públicas porque el ciclo de retroalimentación es demasiado lento. Mantenga su canalización en menos de 3 minutos para pelusa, tipos y pruebas unitarias. Si lleva más tiempo, está probando demasiado o sus pruebas tienen un alcance deficiente.

No probando nada.Sin pruebas, no hay red de seguridad. Enviarás errores más rápido, claro, pero también pasarás las mañanas arreglando lo que enviaste la noche anterior. Comience con entre 10 y 20 pruebas que cubran su lógica empresarial principal y crezca a partir de ahí.

Sin entorno de puesta en escena.La implementación directa desde un PR a producción significa que cada fusión es una apuesta. La puesta en escena le brinda una última oportunidad de detectar problemas en un entorno que refleja la producción. El costo es de $0 en el nivel gratuito de Vercel y de $5 a $20 al mes en Railway.

Despliegue el viernes a las 17 h.Éste es un problema cultural, no técnico. Si algo se rompe, no hay nadie para arreglarlo. Sus usuarios pasan el fin de semana con un producto roto y su equipo pasa el lunes por la mañana controlando daños. Establezca una regla de equipo: no se implementa producción después de las 3:00 p. m. los viernes. Mejor aún, no se implementa producción los viernes.

Cómo Savi configura cada proyecto

Configuramos CI/CD como parte de cada compilación, no como una ocurrencia tardía. Esto es lo que incluye cada proyecto de Savi desde el primer día.

Acciones de GitHub para CI.Cada PR desencadena un flujo de trabajo que ejecuta ESLint, verificación de tipos de TypeScript y el conjunto de pruebas. Si algún paso falla, el RP no se puede fusionar. Las reglas de protección de sucursales hacen cumplir esto para que nadie pase por alto el oleoducto, ni siquiera el líder del proyecto.

Vercel o Ferrocarril para CD.Las aplicaciones frontend se implementan en Vercel con URL de vista previa automática en cada PR y se implementan en producción al fusionarse con el principal. Los servicios backend se implementan en Railway con el mismo patrón de activación. Ambas plataformas manejan reversiones si una implementación no supera las comprobaciones de estado.

La vista previa se implementa en cada PR.Los clientes y partes interesadas obtienen una URL activa para cada rama de funciones. Revisan en el navegador, dejan comentarios sobre las relaciones públicas y aprueban antes de que el código llegue a producción. Esto reemplaza las llamadas de demostración y las grabaciones de pantalla con interacción directa.

Comprobación de tipos y linting automatizados.Ejecutamos TypeScript estricto sin nada implícito y ESLint con reglas ajustadas para detectar errores reales, no preferencias de estilo. Estas comprobaciones añaden entre 15 y 30 segundos al proceso y detectan entre el 60 y el 70 % de los problemas antes de que un revisor humano siquiera mire el código.

Esta configuración tarda una tarde en configurarse al inicio de un proyecto. Se ejecuta automáticamente durante toda la vida útil del producto. El retorno de la inversión se mide en errores que nunca llegan a producción, implementaciones que nunca salen mal y horas de ingeniería que se destinan a funciones en lugar de a combatir incendios.

Preguntas frecuentes