CD - Implementación en staging

Introducción

La implementación continua (CD) es la etapa en la que el software validado se entrega a un entorno donde puede ejecutarse.

Piense de nuevo en nuestra fábrica de software.

1. CI: el robot comprueba si hay defectos.
2. Artefacto: el robot empaqueta el producto en una caja.
3. CD: el camión de reparto lleva la caja a la tienda (el servidor) para que los clientes puedan utilizarla.

En el mundo real, la implementación suele consistir en actualizar sistemas en ejecución mediante SSH, API o mecanismos de publicación específicos de cada plataforma. En este laboratorio, simulará ese proceso, pero la lección importante es el flujo de entrega desde el código probado hasta el entorno en ejecución.

Esta es la diferencia fundamental entre CI y CD. CI demuestra que los cambios de software tienen la calidad suficiente para considerar su entrega, mientras que CD gestiona el traslado controlado de esos cambios validados a un entorno.

En este laboratorio, usted:

• Aprenderá el concepto de desencadenadores manuales (implementación mediante un clic).
• Escribirá un flujo de trabajo de implementación que simula el proceso real.
• Conectará su «camión de reparto» (CD) con su «control de calidad» (CI).

Requisitos previos

Continuará utilizando el repositorio github-actions-basics.

Crear una implementación manual

A veces no querrá implementar el software cada vez que envíe código. Es posible que prefiera esperar una aprobación o implementar solo cuando esté preparado.

Por eso son habituales los desencadenadores manuales y los entornos por etapas. Las canalizaciones de entrega suelen equilibrar la rapidez con la prudencia operativa, en lugar de implementar inmediatamente en producción cada compilación correcta.

GitHub Actions permite crear flujos de trabajo que solo se ejecutan cuando usted hace clic en un botón. Para ello, se utiliza el desencadenador workflow_dispatch.

Vaya al directorio de flujos de trabajo del proyecto.

cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics

Nota: sustituya your-username por su nombre de usuario real de GitHub.

Cree un archivo nuevo llamado deploy.yml.

touch .github/workflows/deploy.yml

Ábralo con nano.

nano .github/workflows/deploy.yml

Añada el siguiente contenido:

name: Deploy to Production

on: workflow_dispatch

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploying
        run: echo "Starting deployment..."

¿Ve on: workflow_dispatch? Ese es el botón mágico.

Guarde el archivo y salga de nano. Después, envíe este archivo a GitHub.

git add .
git commit -m "Add manual deployment workflow"
git push

Ahora vaya a la pestaña Actions de GitHub.

1. Haga clic en Deploy to Production en la barra lateral izquierda.
2. Verá un banner azul con el mensaje «This workflow has a dispatch event trigger.».
3. Haga clic en el botón Run workflow y, después, en el botón verde Run workflow del menú desplegable.

¡Acaba de desencadenar manualmente una canalización de implementación!

Simular los pasos de implementación

Los scripts de implementación reales pueden ser complejos, pero normalmente siguen un patrón sencillo:

1. Conectarse al servidor.
2. Extraer la nueva versión del software.
3. Reiniciar la aplicación.

Aunque los detalles de implementación varíen, la mayoría de las canalizaciones de implementación siguen esta estructura general: autenticarse, obtener el artefacto deseado y hacer que el entorno en ejecución lo utilice.

Actualicemos deploy.yml para simular estos pasos. Usaremos comandos echo para mostrar lo que ocurriría.

Vuelva a abrir el archivo.

nano .github/workflows/deploy.yml

Sustituya la sección jobs por esta simulación más detallada:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Mock SSH Connection
        run: echo "Connecting to production server at 192.168.1.1..."

      - name: Pull New Image
        run: |
          echo "Logging into Registry..."
          echo "Pulling image ghcr.io/myname/app:latest..."

      - name: Restart Application
        run: |
          echo "Stopping old container..."
          echo "Starting new container..."
          echo "Deployment Successful!"

Guarde el archivo y salga. Envíe los cambios.

git add .
git commit -m "Update deployment steps"
git push

Vuelva a GitHub Actions y ejecute manualmente otra vez el flujo de trabajo Deploy to Production. Observe los registros. ¡Parece una implementación real!

Esta técnica de «simulación» es muy útil. En el ámbito profesional, a menudo escribimos primero estos flujos de trabajo «esqueleto» para acordar el proceso antes de escribir el código complejo real.

Añadir comprobaciones de seguridad

En este momento, nuestro flujo de trabajo de «implementación» está completamente separado del flujo de trabajo de «pruebas» (CI). Sin embargo, en la vida real, nunca querrá implementar código defectuoso. Solo querrá que el camión de reparto salga si el control de calidad se supera correctamente.

Podemos vincular flujos de trabajo mediante la palabra clave needs, pero funciona mejor dentro de un solo archivo. Para archivos independientes, normalmente lo gestionamos mediante el proceso: CI se ejecuta al hacer Push, mientras que CD se ejecuta al publicar una Release o de forma manual.

Sin embargo, aprenderemos a añadir una comprobación de seguridad incluso a nuestra implementación manual. Supondremos que solo queremos implementar cuando estemos completamente seguros.

Abra deploy.yml.

nano .github/workflows/deploy.yml

Añadamos una simulación de protección de environment. Modifique steps para incluir una pausa.

steps:
  - name: Safety Check
    run: echo " verifying that CI passed..."

  - name: Mock SSH Connection
    run: echo "Connecting to production server at 192.168.1.1..."
  ## ... rest of the file

(Nota: en una configuración empresarial real, usaríamos una función llamada GitHub Environments para exigir que «CI debe superarse correctamente» antes de que este trabajo pueda ejecutarse, pero eso requiere configuración fuera de este archivo).

Por ahora, guarde el archivo y salga. Después, envíe los cambios.

git add .
git commit -m "Add safety check"
git push

Ejecute manualmente el flujo de trabajo una última vez.

Resumen

¡Enhorabuena! Ha completado el módulo CICD de GitHub Actions.

En este laboratorio final, ha aprendido:

• Desencadenadores manuales: cómo utilizar workflow_dispatch para controlar las implementaciones.
• Simulación: cómo crear un prototipo de un proceso de implementación mediante pasos simulados.
• Visión general: cómo encajan CI, los artefactos, la seguridad y CD.

Comenzó sin conocimientos de GitHub Actions y ahora tiene un repositorio completamente funcional con scripts automatizados de pruebas, empaquetado e implementación. ¡Está preparado para empezar a automatizar sus propios proyectos!