Cómo configurar la integración continua en GitLab usando Docker

En el pasado, es posible que haya intentado usar varios programas y herramientas para implementar aplicaciones de manera efectiva. En este artículo, le mostraré una forma rápida y sencilla de configurar la integración continua para su entorno mediante GitLab y Docker. ¡Entonces empecemos!

Lista de lo que vamos a prestar atención a:

• Control de versiones
• Seguimiento de problemas
• Documentación
• Integración continua
• emisión continua
• Repositorios (defectos/imágenes acoplables)

Jenkins hace un trabajo bastante bueno con la integración y el pago continuos. Mantis hace un gran trabajo al rastrear posibles problemas. Sin embargo, para lograr una mayor eficiencia y calidad de nuestro proyecto, necesitamos combinar estas herramientas. Por ejemplo, en el futuro es posible que deseemos que git-commit se conecte directamente a los problemas existentes o ejecute pruebas automáticas después de actualizar las confirmaciones de la rama maestra.

Generalmente, la mayoría de las herramientas brindan integración con otros servicios comunes de forma predeterminada. Sin embargo, todavía son difíciles de configurar. Además, todo el flujo de trabajo se verá interrumpido si se desactiva algún servicio de la cadena. Por lo tanto, sería genial que hubiera una única plataforma para realizar estas tareas, por eso elegí  GitLab.

CI de GitLab

GitLab.com  es un servicio basado en SAAS, una forma de computación en la nube, donde puede hospedar fácilmente sus repositorios de Git, rastrear problemas potenciales y escribir wikis utilizando el lenguaje Markdown. GitLab CI  también le permite configurar la integración continua utilizando cualquiera de las imágenes de Docker disponibles en  Docker Hub . ¡Veámoslo con un ejemplo!

GitLab CI YML

GitLab CI usa el archivo .gitlab-ci.yml YAML para definir las configuraciones del proyecto, que incluyen la definición de todas las etapas que se ejecutarán después de que se inicie la canalización de CI/CD en respuesta a un git push/merge. En este ejemplo, necesitamos realizar una prueba unitaria de un proyecto simple de Node.js para asegurarnos de que no haya errores en el código. Para que quede más claro, intente ejecutar este  repositorio usted mismo .

stages:
  - lint-css
  - lint-js
  - unit-test

image: node:6.11.2


lint css:
  stage: lint-css
  before_script:
    - npm install
  cache:
    untracked: true
  only:
    - master
  script:
    - ./node_modules/gulp/bin/gulp.js lint-css

lint js:
  stage: lint-js
  cache:
    untracked: true
    policy: pull
  only:
    - master
  script:
    - ./node_modules/gulp/bin/gulp.js lint-js

run unit test:
  stage: unit-test
  cache:
    untracked: true
    policy: pull
  only:
    - master
  script:
    - ./node_modules/gulp/bin/gulp.js test

En el archivo de configuración YAML anterior, hemos dividido todo en 3 pasos. Cada una de las etapas es solo una gulp.task definida en gulpfile.js. Como tenemos instalado Node.js, el usuario puede ejecutar cualquiera de los pasos individualmente. Pero GitLab CI requiere que especifique qué imagen de Docker desea. En nuestro caso, este es el nodo: 6.11.2. Además, este atributo de Docker se puede configurar dentro de una etapa en particular, por lo que puede usar diferentes herramientas para cualquiera de las etapas.

Definición de etapa

Echemos un vistazo más profundo a esta etapa.

lint css:
  stage: lint-css     # <- Should map to the value defined in the 'stages'
  before_script:      # <- Pre-script
    - npm install
  cache:              # <- Enable caching on files so they are available in the next stage
    untracked: true   # <- Cache the git untracked files (ex. node_modules)
  only:
    - master          # <- This stage run only on master branch update
  script:             # <- The actually script of this stage
    - ./node_modules/gulp/bin/gulp.js lint-css

Los atributos before_script y script pueden tener varios valores (array en .yml), si el script falla, todo el paso se clasificará como no válido.

Lanzamiento de tubería (proceso de desarrollo)

En la configuración, preste atención a la pestaña Pipeline en el menú CI / CD. Allí se puede ver toda la historia del proceso de desarrollo.

Echemos un vistazo más de cerca a esta etapa.

Al hacer clic en un Pipeline específico, puede leer la salida detallada de la consola de cualquiera de las etapas. Esto es útil cuando se producen fallos de funcionamiento.

Beneficios de usar GitLab CI con Docker

Diferentes proyectos pueden requerir diferentes plataformas como Node.js, Ant, Maven. Anteriormente, con la herramienta Jenkins , tenía que asegurarme de que todas las plataformas estuvieran instaladas en el servidor. Con  Docker , puede hacer referencia a las dependencias disponibles en  Docker Hub  sin pedirle al administrador del servidor que instale esas dependencias en el propio servidor. De hecho, Jenkins tiene un complemento para crear un Pipeline y también puede funcionar con Docker. Pero como dije antes, tendrás que estar constantemente al tanto de sus actualizaciones, lo cual no es tan bueno en términos de esfuerzo y tiempo adicional.

Aunque prefiero usar  GitLab CI , esto no significa que pueda reemplazar completamente a la herramienta Jenkins . De hecho, Jenkins tiene una gran ventaja: es una interfaz de usuario conveniente y fácilmente personalizable que será conveniente no solo para los desarrolladores, sino también para el control de calidad (especialista en control de calidad) para realizar ciertas tareas, como la implementación y las pruebas de integración.

Al elegir la herramienta adecuada, sepa que no tiene que ser perfecta.

La clave del éxito no está en elegir la herramienta perfecta. El elemento principal del éxito son las personas que lo utilizan. Por lo tanto, antes de buscar una nueva herramienta o programa, intente identificar primero el problema que le gustaría resolver.

Fuente:

https://elsolitario.org/post/configurar-la-integracion-continua-en-gitlab-usando-docker/