La Integración y Despliegue Continuo, o CI / CD, es el proceso de racionalizar y acelerar el desarrollo mediante la construcción y prueba automática de cada compromiso para su proyecto. GitLab integra CI / CD en su archivo git solución extremadamente bien y le mostraremos cómo configurarlo y trabajar con él.
Configurar un servidor de compilación (GitLab Runner)
Compilar el código a menudo puede ser un gran desafío. No todos los lenguajes tienen este problema, pero algunos, como C ++, pueden tardar más de media hora en completar una compilación complicada. Chromium, por ejemplo, puede tardar más de una hora incluso en sistemas de 12 núcleos, como se muestra aquí en este gráfico de GamersNexus.
El tiempo es dinero, por lo que muchas empresas optarán por tener servidores de compilación dedicados, a menudo un enjambre de servidores, y ejecutar sus canalizaciones de CI / CD en hardware potente.
Si no es autohospedado y, en cambio, utiliza la solución SaaS en línea de GitLab (gitlab.com), deberá pagar los minutos de CI / CD. El nivel gratuito incluye 400 minutos de CI / CD, que deberían ser suficientes para proyectos simples, especialmente lenguajes como JS, donde todo lo que se necesita es una base. npm build. Los niveles más altos, que se cobran por usuario, ofrecen mucho más tiempo de construcción. Puede ver los totales actualizados desde la página de información de precios de GitLab.
En nuestro caso, somos autohospedados, por lo que tendremos que configurar un GitLab Runner, que se instala en un servidor y lo configura como agente de compilación. Está disponible como distribución binaria y de Kubernetes, lo que puede ser ideal para implementaciones de múltiples servidores de autoescala.
Afortunadamente, el proceso de instalación es sencillo. Deberá encontrar qué binario necesitará para su host y descargarlo. Para sistemas basados en Debian como Ubuntu, esa sería la deb paquete:
curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"
E instalarlo con dpkg:
sudo dpkg -i gitlab-runner_amd64.deb
A continuación, necesitará configurarlo con URL y el token que se encuentra en / admin / runners.
sudo gitlab-runner register
Se le pedirá que especifique qué ejecutante debe usar este corredor. En la mayoría de los casos, puede usar "docker", con una imagen predeterminada como ubuntu.
Una vez configurado, puede iniciar el corredor:
sudo gitlab-runner register
Entonces debería verlo en la lista.
En nuestro caso, hubo un error extraño en el que el corredor no comenzó porque el /var/lib/gitlab-runner carpeta no estaba presente. La creación manual resolvió el problema de inmediato:
sudo mkdir /var/lib/gitlab-runner
Deberá abrir la configuración del corredor y establecer las etiquetas apropiadas que se recopilarán al hacer coincidir los archivos de configuración gitlab-ci.yml. Si no le interesan las etiquetas, puede marcar esta casilla aquí para recopilar trabajos sin etiquetar:
A continuación, deberá configurar sus diseños para usar este corredor.
Configuración de CI / CD para el proyecto
La configuración de GitLab CI se realiza con un archivo en la raíz del proyecto, llamado .gitlab-ci.yml. Se utiliza automáticamente para realizar.
Por supuesto, la configuración exacta de esto dependerá mucho de ti y de tus necesidades. Un buen lugar para comenzar sería ver cómo otros lo han hecho para su idioma y tiempo de ejecución.
Por ejemplo, una simple compilación de .NET se puede hacer usando una configuración como la siguiente:
image : microsoft/dotnet:latest
stages:
- build
before_script:
- 'dotnet restore'
build:
stage: build
script:
- 'dotnet build'
Primero, necesitamos configurar la imagen de Docker que GitLab usará para construir su aplicación. Esto es importante porque, de lo contrario, el entorno no tendrá el tiempo de ejecución .NET. Primero que nada, funciona dotnet restore, luego corre dotnet build para construir realmente la aplicación.
Para obtener más información sobre la estructura de este archivo, puede consultar la documentación de GitLab.
Una vez comprometida con su repositorio, esa confirmación activará la primera canalización. Puede ver los resultados del pipeline en CI / CD> Pipeline, donde verá cada ejecución junto con su estado.
Si hace clic en los detalles, puede depurar lo que salió mal con la ejecución fallida, ya que mantiene un registro de la consola.
Descubre más contenido