Integración y Despliegue Continuos (CI/CD)

La implementación de CI/CD (Integración Continua/Despliegue Continuo) nos permite automatizar el proceso de actualización del Wiki, asegurando que cualquier cambio aprobado en el repositorio se despliegue automáticamente en el servidor.

Esquema de trabajo

El flujo de trabajo implementado sigue el siguiente esquema:

1. Los desarrolladores trabajan en la rama dev
2. Cuando los cambios están listos, se crea un Pull Request hacia main
3. El COO (Gerardo Alpuche) revisa y aprueba los cambios
4. Al fusionar los cambios en main, se activa automáticamente el despliegue
5. GitHub Actions ejecuta el workflow de despliegue
6. Los cambios se aplican en el servidor de producción

Script de despliegue en el servidor

Primero, creamos un script de despliegue en el servidor:

mkdir -p /root/scripts
nano /root/scripts/deploy.sh

Contenido:

#!/bin/bash

cd ~/GitHub/repositories/neodigital-wiki
git pull origin main
docker build -t neodigital-wiki:latest .
docker stop wiki || true
docker rm wiki || true
docker run -d -p 3000:80 --name wiki --restart always neodigital-wiki:latest
echo "Despliegue completado: $(date)" >> /var/log/deployments.log

Hacemos el script ejecutable:

chmod +x /root/scripts/deploy.sh

Configuración de clave SSH para GitHub Actions

Para permitir que GitHub Actions se conecte al servidor, generamos una clave SSH específica:

ssh-keygen -t ed25519 -f ~/.ssh/github-actions-key -N ""
cat ~/.ssh/github-actions-key.pub >> ~/.ssh/authorized_keys
cat ~/.ssh/github-actions-key

La salida de este último comando debe copiarse para usarla como secret en GitHub.

Configuración del workflow en GitHub Actions

Creamos el archivo .github/workflows/deploy.yml en el repositorio:

name: Deploy to Digital Ocean Droplet

on:
  push:
    branches:
      - main
  pull_request:
    types:
      - closed
    branches:
      - main

jobs:
  build_and_deploy:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.pull_request.merged == true)
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Build application
        run: npm run build

      - name: Deploy to server via SSH
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd ~/GitHub/repositories/neodigital-wiki
            git pull origin main
            docker build -t neodigital-wiki:latest .
            docker stop wiki || true
            docker rm wiki || true
            docker run -d -p 3000:80 --name wiki --restart always neodigital-wiki:latest
            echo "Despliegue completado: $(date)" >> /var/log/deployments.log

Este workflow:

1. Se activa con un push directo a main o cuando se fusiona un Pull Request a main
2. Clona el repositorio
3. Configura Node.js y las dependencias
4. Verifica el código con lint
5. Construye la aplicación localmente para asegurar que no hay errores
6. Se conecta al servidor vía SSH usando los secretos configurados
7. Ejecuta los comandos de despliegue (similar al script deploy.sh)

Configuración de secretos en GitHub

Para que el workflow funcione, necesitamos configurar secretos en GitHub:

1. En el repositorio de GitHub, vamos a Settings > Secrets and variables > Actions
2. Añadimos los siguientes secrets:
   • SSH_HOST: IP del servidor (164.92.117.29)
   • SSH_USERNAME: usuario (root)
   • SSH_PRIVATE_KEY: clave SSH privada generada anteriormente

Protección de la rama main

Para asegurar que todos los cambios pasen por el proceso de revisión:

1. En el repositorio de GitHub, vamos a Settings > Branches
2. En “Branch protection rules”, hacemos clic en “Add rule”
3. En “Branch name pattern” escribimos main
4. Marcamos las siguientes opciones:
   • “Require pull request reviews before merging”
   • “Require review from Code Owners”
   • “Include administrators”
5. Hacemos clic en “Create”

Verificación del CI/CD

Para verificar que el CI/CD funciona correctamente:

1. Creamos una rama de prueba:

   git checkout -b test-ci-cd

2. Realizamos un cambio pequeño, por ejemplo en README.md:

   echo "# Test CI/CD" >> README.md

3. Enviamos los cambios:

   git add README.md
   git commit -m "Test: verificar CI/CD"
   git push origin test-ci-cd

4. Creamos un Pull Request en GitHub desde test-ci-cd hacia main

5. Asignamos a Gerardo Alpuche como revisor

6. Una vez aprobado y fusionado, verificamos en la pestaña “Actions” que el workflow se ejecute correctamente

7. Verificamos en el servidor que los cambios estén aplicados

Monitoreo de despliegues

Para monitorear los despliegues en el servidor:

# Ver el log de despliegues
tail -f /var/log/deployments.log

# Ver el estado del contenedor
docker ps
docker logs -f wiki

Siguientes pasos

Con el CI/CD configurado, establecemos los procedimientos para el mantenimiento continuo del sistema.