Un pipeline CI/CD es un flujo de trabajo automatizado que optimiza el proceso de desarrollo de software, desde la integración continua (CI) hasta la entrega o despliegue continuo (CD). Su objetivo principal es reducir el tiempo de desarrollo y mejorar la calidad del software a través de la automatización de tareas como compilación, pruebas e implementación.
Esta publicación se ha diseñado como una guía práctica para crear pipelines usando recursos gratuítos de acceso libre, en el que se se podrá...
- Entender cómo crear workflows personalizados.
- Hacer uso de los workflows para construir una pipeline CI/CD.
- Aplicar estas pipelines a cualquier proyecto.
Esta formación está orientada principalmente a desarrolladores/as de software que quieran adoptar la cultura DevOps/GitOps y automatizar sus flujos de trabajo y despliegue.
La metodología de esta guía se basa en:
- Teoría y conceptos, con explicaciones claras y concisas de los puntos clave.
- Ejemplo de implementación.
Para aprovechar al máximo este recurso se necesita:
- Un equipo con acceso a Internet.
- Conocimientos básicos de desarrollo web.
- Cuenta en GitHub.
Una pipeline es una secuencia automatizada de pasos que se ejecutan de forma ordenada para construir, probar y desplegar tu software cada vez que hay cambios en el repositorio.
En otras palabras, con un repositorio determinado...
- Lo compila o construye.
- Ejecuta pruebas para verificar que funciona.
- Lo despliega automáticamente si todo está bien.
Una pipeline de integración contínua y de despliegue/entrega contínua asegura que cada cambio pase por un proceso de calidad y despliegue sin intervención manual, manteniendo tu proyecto siempre listo para producción.
- Integración Contínua (CI)
- En esta fase se automatizan las pruebas y construcciones cada vez que se produce un cambio en el repositorio, detectando de manera temprana los posibles errores.
- Entrega/Despliegue Continuo (CD)
- En esta fase se automatiza el despliegue a producción (o de stage) de la aplicación tras pasar las pruebas.
GitHub Actions es el sistema de automatización de GitHub para crear pipelines CI/CD directamente en tu repositorio usando archivos YAML. Permite ejecutar workflows en eventos como push, pull_request o en cron programados.
- Workflow
- El pipeline en sí. Se define en .github/workflows/
- Job
- Una unidad de trabajo que puede correr en paralelo o secuencial según dependencias.
- Step
- Pasos dentro de un job (instalar dependencias, correr tests, build, deploy).
- Action
- Una acción reutilizable (por ejemplo, actions/checkout@v4 para clonar tu repo)
name: CI
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Install Composer dependencies
run: composer update --no-interaction --prefer-dist --ansi
- name: Unit Testing
run: vendor/bin/phpunit
...
- Integración nativa con GitHub.
- Fácil de configurar sin herramientas externas.
- Gran ecosistema de actions reutilizables de la comunidad.
- Escalable para proyectos personales o empresas.
- Mantén workflows pequeños y legibles.
- Usa cachés (actions/cache) para acelerar builds.
- Configura secrets para credenciales de despliegue.
- Incluye linting y pruebas en tu pipeline para mantener calidad.
- Automatiza despliegues a entornos controlados (Vercel, AWS, etc.) al aprobar PRs.
Veamos con un ejemplo práctico cómo crear una pipeline CI/CD con GitHub Actions.
Vamos a crear nuestro workflow en el siguiente fichero: .github/workflows/ci.yml
name: Continuous Integration
on:
push:
branches: ["main"]
pull_request:
branches: ["main"]
permissions:
contents: read
jobs:
test:
name: Check & Tests
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Build the Docker image
run: run: docker build --file docker/Dockerfile --target build-development --tag pipelines:dev .
- name: Validate composer.json and composer.lock
run: docker run --rm --interactive --mount type=bind,source="$(pwd)"/src,target=/var/www/html pipelines:dev composer validate --ansi --working-dir=. --strict
- name: Install Composer dependencies
run: docker run --rm --interactive --mount type=bind,source="$(pwd)"/src,target=/var/www/html pipelines:dev composer install --ansi --working-dir=. --no-interaction --no-progress
- name: Check Syntax
run: docker run --rm --interactive --mount type=bind,source="$(pwd)"/src,target=/var/www/html pipelines:dev composer check-syntax --ansi
- name: Check Style
run: docker run --rm --interactive --mount type=bind,source="$(pwd)"/src,target=/var/www/html pipelines:dev composer check-style --ansi
- name: Check PHPStan
run: docker run --rm --interactive --mount type=bind,source="$(pwd)"/src,target=/var/www/html pipelines:dev composer phpstan --ansi
- name: Check PHPUnit
run: docker run --rm --interactive --mount type=bind,source="$(pwd)"/src,target=/var/www/html pipelines:dev composer paratest --ansi
Este ejemplo realiza las comprobaciones dentro de una imágen Docker personalizada. De este modo podemos comprobar que las pruebas se hacen en un entorno configurado con las extensiones y dependencias específicas.
Vamos a crear nuestro workflow en el siguiente fichero: .github/workflows/cd.yml
name: Continuous Deployment
on:
workflow_dispatch:
workflow_run:
workflows: ["Continuous Integration"]
types: ["completed"]
permissions:
contents: read
jobs:
build-and-deploy:
name: Build & Deploy
runs-on: ubuntu-latest
steps:
- name: Deploying via SSH
uses: appleboy/ssh-action@v1.2.2
with:
host: ${{ secrets.HOST }}
port: ${{ secrets.PORT }}
user: ${{ secrets.USERNAME }}
password: ${{ secrets.PASSWORD }}
script: |
sudo apt update && sudo apt upgrade -y
docker buildx prune --force
mkdir --parents /path/to/application
git -C /path/to/application/ pull || git clone git@github.com:AlcidesRC/application.git /path/to/application/
cd /path/to/application/
git fetch -ap && git reset --hard && git clean -fd && git pull
make deploy
Por cuestiones de seguridad se aconseja hacer uso de GitHub Secrets para no exponer los parámetros de conexión SSH en el workflow.
Cabría la posibilidad de crear la imagen de producción y registrarla en el Container Registry de GitHub, de hecho, se recomienda hacerlo. Pero en aras de hacer esta publicación más accesible, queda a tu elección el mejorar el flujo con los pasos que consideres oportunos :-)