Integración Continua y Desarrollo Continuo (CI/CD)

La integración continua y el desarrollo continuo (CI/CD) es una nueva metodología que está ganando un gran espacio en la industria del software y ganó popularidad en menos tiempo debido a sus características. Sin embargo, hay muchas empresas que ya han iniciado el proceso de desarrollo de software con esta metodología y otras están en este camino. Hay muchas ventajas de CI/CD, que atrajeron a los desarrolladores y a la industria del software, y algunas son las siguientes:

Velocidad: la integración continua está destinada a ser rápida con retroalimentación instantánea
Precisión: aplicar la automatización al proceso de implementación es un gran punto de partida
Confiabilidad: tener una canalización de CI/CD confiable mejora significativamente la velocidad de creación e implementación de nuevas confirmaciones
Cambios de código más pequeños: mediante pruebas continuas, estas pequeñas piezas se pueden probar tan pronto como se integren en el repositorio de código.
Tasa de lanzamiento más rápida: las fallas se detectan más rápido y, como tales, se pueden reparar más rápido, lo que lleva a mayores tasas de lanzamiento

Etapas de CI/CD

No hay etapas definidas de CI/CD. Sin embargo, CI/CD es una metodología muy flexible y los desarrolladores pueden establecer estas etapas según su elección. A continuación, hay algunas opciones estándar de etapas de CI/CD y todas están en proyecto si las etapas anteriores fallan, no pasará a la siguiente etapa.

Control de Versiones: Se utiliza para gestionar los cambios de código, documentación, etc. Por ejemplo, GitLab, GitHub, TFS, etc.
Construir: esta etapa construye la solución del producto de software y almacena los artefactos
Prueba unitaria: después de construir con éxito la solución en la etapa 2, se realizará una prueba unitaria, si tiene alguna.
Implementar: después de las etapas de construcción y prueba unitaria exitosas, la solución se implementará en un entorno temporal.
Prueba automatizada: esta etapa ejecutará todas las pruebas automatizadas para verificar que el producto pueda cumplir con todos los requisitos antes de que se implemente en producción.
Implementar en producción: después de ejecutar con éxito todos los casos de prueba y verificación, ahora esta etapa implementará el producto en un entorno de producción.

Hay muchas herramientas de software disponibles que proporcionan una implementación de CI/CD, y algunas se encuentran a continuación y pueden ser utilizadas por los desarrolladores o la elección de las empresas y cada una tiene sus propias características:

Jenkins
Circuloci
ciudadequipo
Bambú
GitLab

Requisitos de CI/CD de GitLab

Puede haber cualquier herramienta de software para implementar CI/CD como se mencionó anteriormente. Sin embargo, GitLab proporciona la implementación de CI/CD de manera flexible, y sin mucho conocimiento u otro software adicional, cualquier persona que tenga algunos conocimientos básicos sobre el desarrollo de software puede configurar fácilmente la configuración de CI/CD con GitLab. A continuación se presentan algunos requisitos:

Control de versiones : GitLab es en sí mismo un control de versiones para implementar CI/CD
GitLab Runner: es una herramienta importante para implementar CI/CD y debe instalarse antes de cualquier configuración de CI/CD. Recoge y ejecuta trabajos para GitLab cuando alguien confirma los cambios. Hay dos tipos de corredores: corredores compartidos y corredores específicos.
- Corredor compartido: estos corredores ejecutan código de diferentes proyectos en el mismo corredor y usan corredores compartidos cuando tiene varios trabajos con requisitos similares.
- Runner específico: es un runner individual y cada proyecto será ejecutado por un runner separado y administrado por el único desarrollador que está trabajando en este proyecto específico.
Ejecutores de GitLab Runner: GitLab Runner implementa una serie de ejecutores que se pueden usar para ejecutar compilaciones en diferentes escenarios. Hay varios ejecutores disponibles en GitLab, que se pueden implementar de acuerdo con los requisitos del proyecto o la disponibilidad de las herramientas de software. Algunos ejecutores están a continuación:
- SSH: el ejecutor SSH solo admite scripts generados en Bash y la función de almacenamiento en caché actualmente no es compatible. Este es un ejecutor simple que le permite ejecutar compilaciones en una máquina remota ejecutando comandos a través de SSH.
- Shell: Shell es el ejecutor más simple de configurar. Todas las dependencias requeridas para sus compilaciones deben instalarse manualmente en la misma máquina en la que está instalado Runner.
- Parallels: Esta configuración de ejecutor se usa con Virtual Box.
- VirtualBox: este tipo de ejecutor permite usar una máquina virtual ya creada, que se clona y se usa para ejecutar su compilación.
- Docker: una excelente opción es usar Docker, ya que permite un entorno de compilación limpio, con una gestión de dependencias sencilla (todas las dependencias para compilar el proyecto se pueden colocar en la imagen de Docker).
- Docker Machine (escalado automático): Docker Machine es una versión especial del ejecutor de Docker compatible con el escalado automático. Funciona como el ejecutor normal de Docker pero con la compilación, hosts creados a pedido por Docker Machine.
- Ejecutor de Kubernetes: el ejecutor de Kubernetes permite usar un clúster de Kubernetes existente para sus compilaciones.
- Ejecutor personalizado: El ejecutor personalizado permite especificar sus propios entornos de ejecución.
Archivo Yml: Se necesita un archivo Yml para ejecutar el CI/CD y deberá almacenarse en un archivo fuente del proyecto, e incluye la configuración de cada tecnología y método de procedimientos.

Ventanas de ejecución de GitLab

Siga los pasos a continuación, descargue GitLab Runner en Windows y siga los comandos para verificarlo y registrarlo.

1. Descargue el ejecutor de GitLab desde https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-windows-386.exe 2. Cree una carpeta en su directorio local (por ejemplo, C :\GitLab-Runner) y cambie el nombre del archivo descargado a gitlab-runner.exe, guárdelo en esta carpeta.

3. Escriba el siguiente comando para verificarlo y registrarlo.

Comandos de ejecución de GitLab

Hay muchos comandos de GitLab Runner si ya están instalados en el sistema, por ejemplo, iniciar GitLab Runner, detener GitLab Runner, registrarse, etc.

Dominio	Descripción
registro gitlab-runner.exe	Registrar el proyecto con CI/CD
inicio de gitlab-runner.exe	Iniciar el corredor
detener gitlab-runner.exe	detener al corredor
estado de gitlab-runner.exe	Para saber el estado de gitlab-runner
gitlab-runner unregister –nombre corredor de prueba	Anule el registro de Runner de un proyecto y reemplace test-runner con su nombre de corredor y este nombre se puede encontrar dentro del archivo config.toml (donde está disponible su gitlab.exe).
anular el registro de gitlab-runner –url http://gitlab.example.com/ –token t0k3n	Eliminar Runner por URL y token
anular el registro de gitlab-runner –todos los corredores	Dar de baja a todos los corredores
reinicio de gitlab-runner	Este comando detiene y luego inicia el servicio GitLab Runner
desinstalación de gitlab-runner	Este comando detiene y desinstala GitLab Runner para que no se ejecute como un servicio
ejecutivo de gitlab-runner	Para ver una lista de ejecutores disponibles, ejecute
gitlab-runner –ayuda	Verifique una lista reciente de comandos ejecutando
ejecución de gitlab-runner –ayuda	puede ver el nombre de la variable de entorno
gitlab-corredor – depuración	Para ejecutar un comando en modo de depuración
Shell ejecutivo de gitlab-runner	Para ver una lista de todas las opciones disponibles para el ejecutor de shell, ejecute

Corredor de GitLab Linux

Siga los pasos a continuación para descargar GitLab Runner en el entorno Linux y siga los comandos a continuación para verificar y registrar un proyecto.

sudo curl -L –output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 [Simplemente descargue uno de los binarios para su sistema]
sudo chmod +x /usr/local/bin/gitlab-runner [Dale permisos para ejecutar]
sudo useradd –comment ‘GitLab Runner’ –create-home gitlab-runner –shell /bin/bash [Crear un usuario de GitLab CI]
sudo gitlab-runner install –user=gitlab-runner –working-directory=/home/gitlab-runner [Instalar y ejecutar como servicio]
inicio de sudo gitlab-runner
Después de realizar la instalación con éxito, GitLab Runner comenzó y puede realizar el registro del repositorio.

Dominio	Descripción
registro sudo gitlab-runner	Registrar el proyecto con CI/CD
inicio de sudo gitlab-runner	Iniciar el corredor
detener sudo gitlab-runner	detener al corredor
estado de sudo gitlab-runner	Para saber el estado de gitlab-runner
sudo gitlab-runner unregister –name test-runner	Anule el registro de Runner de un proyecto y reemplace test-runner con su nombre de corredor y este nombre se puede encontrar dentro del archivo config.toml (donde está disponible su gitlab.exe)
sudo gitlab-runner unregister –url http://gitlab.example.com/ –token	Eliminar Runner por URL y token
sudo gitlab-runner unregister –todos los corredores	Dar de baja a todos los corredores
reinicio de sudo gitlab-runner	Este comando detiene y luego inicia el servicio GitLab Runner
desinstalación de sudo gitlab-runner	Este comando detiene y desinstala GitLab Runner para que no se ejecute como un servicio
ejecución de sudo gitlab-runner	Para ver una lista de ejecutores disponibles, ejecute
sudo gitlab-runner –ayuda	Verifique una lista reciente de comandos ejecutando
sudo gitlab-runner ejecutar –ayuda	Puede ver el nombre de la variable de entorno.
sudo gitlab-runner – depuración	Para ejecutar un comando en modo de depuración
sudo gitlab-runner exec shell	Para ver una lista de todas las opciones disponibles para el ejecutor de shell, ejecute

Configuración del proyecto de Windows CI/CD

Siga los pasos a continuación para configurar CI/CD con proyectos de entorno de Windows:

Vaya a la ruta descargada de gitlab-runner .exe, donde la almacenó, y abra el símbolo del sistema. (siga el comando de Windows anterior)
Verifique el estado de gitlab-runner, deténgalo si ya se está ejecutando antes de registrar cualquier proyecto nuevo con CI/CD
Ahora escriba, registro gitlab-runner.exe y complete los detalles a continuación
Ingrese la URL de su instancia de GitLab: vaya a Cuenta de GitLab -> Seleccione el proyecto que desea implementar CI/CD -> Configuración -> CI/CD
Ingrese el token de gitlab-ci para este corredor: vaya a Cuenta de GitLab -> Seleccione el proyecto que desea implementar CI/CD -> Configuración -> CI/CD .
Ingrese la descripción de gitlab-ci para este corredor: coloque cualquier nombre (por ejemplo: MyRunner1) y esto solo para recordar qué corredor se está ejecutando.
Ingrese las etiquetas de gitlab-ci para este corredor: esta es la etiqueta para iniciar el CI/CD puede poner cualquier nombre o ningún nombre, no es necesario (por ejemplo: mi etiqueta, otra etiqueta)
Ingrese al ejecutor: debe seleccionar un ejecutor de la lista de ejecutores anterior y cada ejecutor tiene sus propias características.
Ahora el proyecto está registrado con éxito e inicie el corredor de GitLab.

Configuración del proyecto Linux CI/CD

Siga los pasos a continuación para configurar CI/CD con Linux Project.

Vaya a su máquina Linux, donde ha instalado GitLab Runner y Git
Verifique el estado del corredor de GitLab, si ya se está ejecutando, deténgalo antes de registrar cualquier proyecto nuevo
Escriba sudo gitlab-runner register -> para registrar el nuevo proyecto con CI/CD
Ahora siga todos los pasos a continuación, al igual que Windows, y complete la información requerida

Agregar archivo Yml en el código fuente

Este es un paso importante para incluir el archivo yml en su directorio de código fuente, si no lo incluye, CI/CD no funcionará. Este archivo incluye una configuración de cómo se ejecutará este proyecto.

Por ejemplo, formato de archivo Yml del proyecto .Net

variables:
NUGET_PATH: ‘C:\Tools\Nuget\nuget.exe’
MSBUILD_PATH: ‘C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\MSBuild.exe’
XUNIT_PATH: paquetes\ xunit.runner.console.2.3.1\tools\net452
UNITTEST_FOLDER: ‘.\tests\CiCdExample.Tests\bin\Release\’

etapas:
– construir
– probar
– desplegar

build_job:
etapa:
solo compilación: – secuencia de comandos
de ramas : – ‘& “$env:NUGET_PATH” restaurar’ – ‘& “$env:MSBUILD_PATH” /p:Configuration=Release /clp:ErrorsOnly’ – ‘& “$env:MSBUILD_PATH ” src\CiCdExample\CiCdExample.csproj /p:DeployOnBuild=true /p:Configuration=Release /P:PublishProfile=FolderProfile.pubxml’ artefactos: expire_in: 20 días rutas: – ‘.\src\CiCdExample\bin\Release\Publish \’ – ‘$env:UNITTEST_FOLDER’ – ‘.\$env:XUNIT_PATH\*.*’

test_job:
etapa:
solo prueba:
– branch
script:
– ‘& “$env:XUNIT_PATH\xunit.console.exe” “$env:UNITTEST_FOLDER\CiCdExample.Tests.dll”’
dependencias:
– build_job

deployment_job:
stage : deployment
only: – script
de ramas : – ‘xcopy /y /s “.\src\CiCdExample\bin\Release\Publish\*.*” “C:\Tools\inetpub\wwwroot\ci-cd-example Dependencias ”’ : – build_job – test_job

Formato de proyecto C/C++ Yml

imagen: gcc

etapas:
– construir
– probar

build_job:
etapa: compilar
solo: – script
maestro : – código fuente del cd – exportar CXX=/usr/bin/g++ – exportar CC=/usr/bin/gcc – chmod -R 777 * – ./compileproject.sh

artefactos:
expire_in: 365 días
rutas:
– sourcecode/testdata_1.0

test_job:
etapa:
solo prueba: – script
maestro : – pwd – ls -lrt sourcecode/testdata_1.0 – cd testDir – chmod -R 777 * – ./runtests.sh

dependencias:
– build_job

Publicación traducida automáticamente

Artículo escrito por amiransarimy y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA