Introducción a CI/CD con GitLab

DevOps: Integración y entrega continúa fácil y rápida con GitLab.

GitLab Logo

Hablemos un poco de este tan sonado tema de DevOps, ¿qué es CI/CD (Continuos Integration & Continuos Delivery/Deployment) y qué significa para la empresa? La integración y entrega continua permite a los equipos construir, probar y liberar software a un ritmo más rápido. CI/CD trata de quitar las interacciones humanas manuales donde es posible — automatizando todo excepto la entrega final manual de código a producción. Uno de los retos de implementar esta práctica es la integración de distintas herramientas y sistemas requeridos para construir un tubería o pipeline de CI/CD. por ejemplo. puede ser que almacenen el código en Bitbucket, hagan pruebas en suites automatizadas en infraestructura privada, y entreguen su aplicación en AWS o Microsoft Azure. Aplicaciones complicadas que residen en multiples sistemas dificultan el proceso de que las empresas implementen una tubería sin costuras, es decir que logren un muy buen flujo CI/CD.

Developing modern software requires an automated pipeline that builds, tests, and deploys your application, complete with its required infrastructure.

¿por qué CI/CD con GitLab?

Pues la primer razón es por que es sencillo, podemos construir un pipeline completo con una sola herramienta. Las otras razones serían por es rápido y es open source. Con CI/CD de GitLab en el mismo lugar , podemos crear tickets, unir solicitudes, escribir código y establecer la integración y entrega continua sin depender de otra aplicación. Es básicamente un viaje sin escalas, GitLab CI/CD corre sus construcciones en una cosa que se llama GitLab Runners. Estos runners son máquinas virtuales aisladas que corren pasos predefinidos a través de la API, GitLab CI API para ser preciso. Esta herramienta, independiente, permite que los proyectos corran a través de los construcciones de pipelines más rápido, comparada a cuando se corren en una sola instancia.

GitLab Runner

GitLab Runner es el proyecto de código abierto que es usado para correr tus trabajos y mandar los resultados de regreso a GiLab. Son usados en conjunción con GitLab CI, el servicio de código abierto de integración continua incluido en Gitlab el cual coordina los trabajos,

Manos a la obra

Vamos a suponer que tenemos un API de Node que trae una lista de libros de una base de datos. Un escenario bastante sencillo y práctico, para no complicar mucho las cosas.

Podemos crear una tubería, — pipeline de ahora en adelante, que empuje nuestro código en 3 fases: construcción, pruebas y entrega. Un pipeline recordemos es un grupo de pasos que son agrupados bajo características similares. Con estas fases o etapas nuestro pipeline es definido en 3 tipos:

• El pipeline del proyecto (Project pipeline)
• El Pipeline de integración continua
• El pipeline de entrega

El pipeline del proyecto instala dependencias, corre los linters y cualquier script que tenga que ver con código. El pipeline de integración continua corre pruebas automatizadas y construye versiones distribuidas del código. Finalmente, el pipeline de entrega, entrega el código a un ambiente de un proveedor de nube designado.

A.) Build
     i. Install NPM Dependencies
     ii. Run ES-Linter
     iii. Run Code-Minifier
B.) Test
     i. Run unit, functional and end-to-end test.
     ii. Run pkg to compile Node.js application
C.) Deploy
     i. Production
        1.) Launch EC2 instance on AWS
     ii. Staging
        1.) Launch on local development server

En esta jerarquía, los tres componentes son considerados tres diferentes pipelines. Las partes importantes — build, test y deploy — son etapas (stages) y cada parte debajo de estas secciones son trabajos. Vamos bajo la óptica de un archivo yaml de GitLab Ci/CD.

YAML es un formato para guardar objetos de datos con estructura de árbol. Sus siglas significan YAML Ain’t Markup Language (YAML no es otro lenguaje de marcado). Este lenguaje es muy legible para las personas, más legible que JSON y sobretodo que XML.

Usando GitLab CI/CD

Para usar GitLab CI/CD, creamos un archivo con nombre .gitlab-ci.yml en la raíz del proyecto e nuestro repositorio de dGitLab y agregamos el siguiente código yaml:

image: node:10.5.0

stages:
  - build
  - test
  - deploy

before_script:
  - npm install

Como mencionamos con anterioridad, GitLab CI/CD usa los Runners para ejecutar los pipelines. Podemos definir que sistema operativo y librerías predefinidas en las cuales queremos basar nuestros runners usando la directiva image. en nuestra instancia, estaremos usando una de las ultimas versiones de Node.js para nuestro runner

La directiva stages permite que pre definamos una etapa para la configuración entera. Los trabajos serán ejecutados basados en el orden listado en la directiva stages.

Para aprender mas acerca de los stages pueden revisar la documentación oficial.

Documentación de CI/CD en GitLab

La directiva before-script es usada para correr un comando antes de todos los trabajos. Ahora vamos a comenzar con nuestro trabajo dedicado a la etapa Build. Vamos a llamar este trabajo build-min-code. Vamos a querer que este trabajo instale las dependencias y minimicé (minifiqué ¿esta bien escrito ?mmm lo investigo) el código. Podemos comenzar esto usando la directiva script, la directiva script es el caparazón del script que se ejecuta dentro del runner. Después vamos a asignar este trabajo a ta etapa “build”. Para asignar un trabaja a la etapa o stage, usamos la directiva stage.

build-min-code:
  stage: build
  script:
    - npm install
    - npm run minifier

Ahora tenemos un trabajo asociado con nuestra etapa de construcción — Build y ahora haremos lo propio par la etapa de prueba — Test.

Nuestro trabajo de prueba sera llamado run-unit-test y vamosa usar el script npm en nuestra API para corre una prueba npm test,

run-unit-test:
  stage: test
  script:
    - npm run test

Suavesongo ¿ no?

Finalmente, vamos a agregar un trabajo para manejar nuestra etapa de entrega — Deploy, se va a llamar: deploy-production, deploy-staging. En esta instancia , vamos a tener dos trabajos diferentes para el deployment (staging y production), como indican las buenas practicas (créanmelo por ahora) . Estos trabajos reflejarán el mismo layout que el trabajo previo pero con un cambio menor. Actualmente , todos nuestros trabajos están automáticamente establecidos para detonarse en cualquier código (push or branch), que se haya mandado a push o a cualquier rama. No queremos tener eso cuando los entregamos nuestro código a staging y menos a producción. Para prevenir que es suceda usamos la directiva only. La directiva only define los nombres de las ramas y etiquetas para los trabajos que deberán correr. El trabajo buscará lo siguiente, por ejemplo:

deploy-staging:
 stage: deploy
 script:
   - npm run deploy-stage
 only:
   - develop

deploy-production:
 stage: deploy
 script:
   - npm run deploy-prod
 only:
   - master

En nuestro trabajo deploy-staging , el Runner ejecutará exclusivamente este si es que hubo un cambio en la rama develop y hacia el deploy-production a la rama master. La imagen a continuación muestra el código que se envia (push) a a la rama a master.

GitLab pipeline from scratch

De esta imagen podemos observar, que los tres estados y trabajos son detonados con excepción de deploy-staging ya que el código enviado fue a la rama master

GitLab CI/CD viene con una intuitiva interface que nos ayuda a mostrar que trabajos y etapas están corriendo y que errores han ocurrido en medio de la construcción. Abajo podemos observar la construcción del archivo .gitlab-ci.yaml. Si quieres probar el resultado por ti mismo, les dejo el link a la aplicación de ejemplo.

image: node:10.5.0

stages:
  - build
  - test
  - deploy

before_script:
  - npm install

build-min-code:
  stage: build
  script:
    - npm install
    - npm run minifier

run-unit-test:
  stage: test
  script:
    - npm run test

deploy-staging:
  stage: deploy
  script:
    - npm run deploy-stage
  only:
    - develop

deploy-production:
  stage: deploy
  script:
    - npm run deploy-prod
  only:
    - master

Conclusión

Esto es un artículo introductor, hay mucho mucho por aprender. Solo se muestran algunas capacidades que ofrece GitLab CI/CD can offer. Pero GitLab tiene la posibilidad de ofrecer un control más a fondo de la automatización de nuestros códigos base, por ejemplo construyendo y publicando images Docker, para integrar con herramientas de terceras partes, por decir algo.

Espero seguir escribiendo y profundizando en el tema. Gracias por leer.

Referencias

Les dejo este artículo (en inglés) What is a CI/CD Engineer?

Y bueno si alguien esta interesado en seguir aprendiendo en KMMX vamos a seguir haciendo los talleres, platicas y demos completamente gratuitos por si están en CDMX y gustan asistir.

Taller de Fundamentos de GitLab en KMMX,

¡Sigan rockeando duro!

Alex