Elegir herramientas según el proyecto

Si una cocina ya tiene una mesa firme, no necesitas cambiarla para preparar una receta nueva. Primero revisas si hay espacio, utensilios y una forma de trabajar. Con CI/CD, empezar por la herramienta de moda puede distraer del recorrido que necesitas construir.

El punto de partida es el proyecto existente. ¿Dónde vive el código? ¿Cómo se construye? ¿Qué comprueba el equipo? ¿Qué necesita el destino? Una plataforma ayuda a ejecutar y observar esas respuestas; no las inventa.

Cinco preguntas antes de comparar logos

1. Repositorio: dónde se revisa y registra el cambio.
2. Ejecución: qué sistema operativo, versión de lenguaje y recursos necesita.
3. Comprobaciones: qué comandos demuestran condiciones importantes.
4. Entrega: dónde se conservan las versiones y cómo se identifican.
5. Destino: cómo se activa, observa y recupera una versión.

En GitHub Actions, un runner ejecuta el trabajo. Puede ser un equipo administrado por la plataforma o uno gestionado por la organización. Esa elección afecta mantenimiento, accesos y aislamiento. Conviene conocer sus responsabilidades antes de elegirlo únicamente por velocidad.

Si el equipo ya usa GitLab y su automatización cubre el proyecto, tener un ejemplo en GitHub no obliga a migrar. El concepto importante es conservar condiciones de avance y evidencia, aunque cambie la sintaxis de los archivos.

La elección del ejercicio

En los fragmentos usaremos Python y GitHub Actions para explicar eventos, trabajos, pasos y entregas. El caso del pedido sigue siendo ficticio. Cada elección ayuda a mostrar una decisión; no pretende ser una arquitectura para todas las aplicaciones ni exige instalar herramientas para seguir la lectura.

Al comparar opciones reales, incluye restricciones de red, capacidad del equipo, requisitos institucionales y coste de mantenerlas. «Tiene integración con todo» ayuda menos que saber si puede ejecutar el comando concreto que necesita tu aplicación.