{"id":69258,"date":"2023-08-21T15:09:06","date_gmt":"2023-08-21T13:09:06","guid":{"rendered":"https:\/\/kinsta.com\/es\/?p=69258&preview=true&preview_id=69258"},"modified":"2023-08-25T17:17:19","modified_gmt":"2023-08-25T15:17:19","slug":"como-configurar-pipeline-ci-cd","status":"publish","type":"post","link":"https:\/\/kinsta.com\/es\/blog\/como-configurar-pipeline-ci-cd\/","title":{"rendered":"C\u00f3mo Crear un Pipeline de CI\/CD con GitHub Actions y la API de Kinsta"},"content":{"rendered":"

En el vertiginoso mundo del desarrollo web<\/a>, la integraci\u00f3n continua y el despliegue continuo (CI\/CD<\/a>) se han convertido en pr\u00e1cticas indispensables para entregar software de alta calidad de forma eficiente. CI\/CD permite a los desarrolladores automatizar el proceso de creaci\u00f3n, prueba y despliegue de los cambios de c\u00f3digo, reduciendo el riesgo de error humano y permitiendo iteraciones m\u00e1s r\u00e1pidas.<\/p>\n

Este art\u00edculo explica la importancia de CI\/CD, c\u00f3mo crear un canal de CI y c\u00f3mo configurar el despliegue continuo en tu canal de CI con la API de Kinsta<\/a> mediante programaci\u00f3n, todo ello con Acciones de GitHub en tu repositorio de GitHub<\/a>.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

\u00bfPor Qu\u00e9 Usar CI\/CD?<\/h2>\n

La plataforma de Alojamiento de Aplicaciones<\/a> de Kinsta siempre ha ofrecido una opci\u00f3n para el despliegue autom\u00e1tico, que se activa cada vez que hay un cambio en una rama espec\u00edfica de tu repositorio Git alojado. Sin embargo, esto puede no ser ideal para grandes proyectos con m\u00faltiples miembros del equipo. Muchos desarrolladores<\/a> tienden a evitar activar el despliegue autom\u00e1tico por diversas razones.<\/p>\n

Una raz\u00f3n es que, en un entorno colaborativo en el que varios desarrolladores trabajan en el mismo proyecto, los despliegues autom\u00e1ticos activados por el cambio de un desarrollador en el repositorio pueden provocar inestabilidad y problemas imprevistos. Sin las pruebas y la validaci\u00f3n adecuadas, incluso un peque\u00f1o cambio en el c\u00f3digo podr\u00eda alterar el sitio en producci\u00f3n, causando potencialmente tiempos de inactividad y experiencias negativas para los usuarios.<\/p>\n

Aqu\u00ed es donde entra en juego un pipeline de CI\/CD. Creando un flujo de trabajo CI\/CD cuidadosamente orquestado, los desarrolladores pueden asegurarse de que los cambios de c\u00f3digo se someten a pruebas y validaci\u00f3n antes de desplegarse en el sitio en producci\u00f3n. Hay muchas herramientas disponibles para implementar CI\/CD en el desarrollo de software, utilizaremos GitHub Actions<\/a> para este tutorial.<\/p>\n

\u00bfQu\u00e9 Es GitHub Actions?<\/h2>\n

GitHub Actions es una potente herramienta de automatizaci\u00f3n proporcionada por GitHub. Ofrece a los desarrolladores la posibilidad de automatizar varias tareas, procesos y flujos de trabajo dentro de sus proyectos de desarrollo de software. Se integra con los repositorios de GitHub, lo que facilita su uso.<\/p>\n

Con las Acciones de GitHub y la API de Kinsta<\/a>, puedes definir flujos de trabajo personalizados que se adapten a los requisitos de tu proyecto. Puedes configurar un pipeline CI que pruebe tu aplicaci\u00f3n y active el despliegue en Kinsta.<\/p>\n

Primeros Pasos con GitHub Actions<\/h2>\n

Las Acciones de GitHub se basan en el concepto de flujos de trabajo, que son conjuntos de tareas automatizadas que se activan por eventos espec\u00edficos o se programan a intervalos regulares. Estos eventos pueden incluir env\u00edos de c\u00f3digo, pull requests, creaci\u00f3n de incidencias, etc. Cuando se produce uno de estos eventos, GitHub Actions ejecuta autom\u00e1ticamente un flujo de trabajo asociado, ejecutando una serie de pasos predefinidos.<\/p>\n

Cada paso del flujo de trabajo representa una acci\u00f3n concreta, como construir el c\u00f3digo, ejecutar pruebas, desplegar o enviar notificaciones. Creemos un flujo de trabajo con tres tareas:<\/p>\n

    \n
  1. Comprobar la sintaxis con ESLint<\/li>\n
  2. Ejecutar pruebas<\/li>\n
  3. Despliega de nuevo tu aplicaci\u00f3n<\/li>\n<\/ol>\n

    Paso 1: Configura Tu Repositorio de GitHub<\/h3>\n

    Para empezar con las Acciones de GitHub, necesitas un repositorio de GitHub.<\/p>\n

    Aqu\u00ed, estamos utilizando este repositorio de GitHub<\/a>, desarrollado para el tutorial C\u00f3mo Construir y Desplegar una Aplicaci\u00f3n Clonada de ChatGPT con React y la API OpenAI<\/a>.<\/p>\n

    Si\u00e9ntete libre de utilizar el repositorio t\u00fa mismo navegando hasta \u00e9l en GitHub y seleccionando: Use this template<\/strong>\u00a0>\u00a0Create a new repository<\/strong> (Usar esta plantilla > Crear un nuevo repositorio<\/strong>).<\/p>\n

    En esta aplicaci\u00f3n React, se crean pruebas unitarias para probar cada componente. Tambi\u00e9n se utiliza ESLint para que la sintaxis y el formato del c\u00f3digo sean perfectos. El pipeline de CI bloquear\u00e1 un despliegue si un pull request o c\u00f3digo fusionado enviado al repositorio no supera las pruebas del flujo de trabajo<\/p>\n

    Paso 2: Crear un Archivo de Flujo de Trabajo<\/h3>\n

    Define tu flujo de trabajo creando un archivo YAML en el directorio .github\/workflows<\/strong> de tu repositorio. Este directorio debe estar en el nivel root de tu repositorio. La convenci\u00f3n de nomenclatura para los archivos de flujo de trabajo es nombre-del-flujo-de-trabajo.yml<\/strong>.<\/p>\n

      \n
    1. En tu repositorio, crea un directorio .github<\/strong>.<\/li>\n
    2. Dentro del directorio .github<\/strong>, crea un nuevo directorio llamado workflows<\/strong>.<\/li>\n
    3. Dentro del directorio workflows, crea un nuevo archivo con un nombre como build-test-deploy.yml<\/strong>.<\/li>\n<\/ol>\n

      Paso 3: Escribe el Flujo de Trabajo CI\/CD<\/h3>\n

      Ahora que has creado tu archivo workflow, define un flujo de trabajo con los pasos necesarios para comprobar la sintaxis con ESLint, ejecutar las pruebas y desplegar la aplicaci\u00f3n.<\/p>\n

      Crear Evento CI<\/h4>\n

      Al crear un flujo de trabajo CI, el primer paso es dar un nombre al flujo de trabajo y, a continuaci\u00f3n, establecer el evento que activar\u00eda el flujo de trabajo. Para este ejemplo, los dos eventos son una solicitud de pull y un push a la rama principal.<\/p>\n

      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"<\/code><\/pre>\n
      Si quieres programar trabajos peri\u00f3dicos (CRON jobs) para tareas espec\u00edficas, puedes a\u00f1adirlos al flujo de trabajo. Por ejemplo, puede que quieras ejecutar ciertas tareas como copias de seguridad de la base de datos, limpieza de datos u otras tareas de mantenimiento peri\u00f3dicas.<\/p>\n
      Aqu\u00ed tienes un ejemplo de c\u00f3mo puedes a\u00f1adir un CRON job al flujo de trabajo:<\/p>\n
      on:\n  # Existing event triggers for push and pull_request\n\n  # Add a schedule for CRON jobs\n  schedule:\n    - cron: \"0 0 * * *\"<\/code><\/pre>\n
      El ejemplo anterior activar\u00e1 el flujo de trabajo todos los d\u00edas a medianoche (hora UTC), ya que la programaci\u00f3n cron est\u00e1 configurada en 0 0 * * *<\/code>. Puedes personalizar la programaci\u00f3n cron para adaptarla a tus necesidades espec\u00edficas.<\/p>\n
      Como otro ejemplo, supongamos que quieres programar el flujo de trabajo CI\/CD para que se ejecute todos los lunes a las 8 a.m. Podemos configurar un CRON job utilizando el evento schedule<\/code>:<\/p>\n
      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"\n\n  # Schedule the workflow to run every Monday at 8 a.m. (UTC time)\n  schedule:\n    - cron: \"0 8 * * 1\"\n\njobs:\n # Add jobs<\/code><\/pre>\n
      La sintaxis de programaci\u00f3n utilizada en el evento schedule<\/code> para los flujos de trabajo de las Acciones de GitHub se basa en la sintaxis cron de UNIX. Te permite definir horas o intervalos espec\u00edficos para que tu flujo de trabajo se ejecute autom\u00e1ticamente. La sintaxis consta de cinco campos que representan diferentes aspectos de la programaci\u00f3n. Cada campo est\u00e1 separado por un espacio. El formato general de la sintaxis de programaci\u00f3n es el siguiente:<\/p>\n
      * * * * *\n\u252c \u252c \u252c \u252c \u252c\n\u2502 \u2502 \u2502 \u2502 \u2502\n\u2502 \u2502 \u2502 \u2502 \u2514\u2500 Day of the week (0 - 7) (Sunday to Saturday, where both 0 and 7 represent Sunday)\n\u2502 \u2502 \u2502 \u2514\u2500\u2500\u2500 Month (1 - 12)\n\u2502 \u2502 \u2514\u2500\u2500\u2500\u2500\u2500 Day of the month (1 - 31)\n\u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Hour (0 - 23)\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Minute (0 - 59)<\/code><\/pre>\n
      Ahora, vamos a desglosar cada campo:<\/p>\n