Introducci贸n

1

Lo que aprender谩s sobre DevOps con GitLab

2

驴Qu茅 es Devops?

3

El ciclo de vida del Devops

4

Introducci贸n a Gitlab

5

Gitlab vs Github

Administraci贸n

6

Autenticaci贸n

7

Grupos

8

Autorizaci贸n

9

Auditor铆a

10

Proyectos

Planificaci贸n

11

Tipos de desarrollo

12

Planificaci贸n en Gitlab-Issues

13

Planificaci贸n en Gitlab-Etiquetas

14

Planificaci贸n en Gitlab-Pesos

15

Planificaci贸n en Gitlab-Milestones

16

Planificaci贸n en Gitlab-Boards

17

Planificaci贸n en Gitlab-Service Desk

18

Planificaci贸n en Gitlab-Quick actions

Verificaci贸n

19

Inicializaci贸n del repositorio

20

Merge requests

21

Profundizando en Merge requests

22

Continuous Integration-CI

23

Gitlab CI

24

Automatizacion con GitLab Cl

25

Validacion de la configuracion con GitLab Cl

26

gitlab-ci.yml

27

Gitlab pages

28

Implementando Gitlab pages

29

驴Qu茅 es el Desarrollo 脕gil?

30

Gitlab autodevops

31

Implementando GitLab autodevops

32

Habilitando autodevops

Empaquetaci贸n

33

Gitlab container registry

34

Introducci贸n a contenedores

Seguridad

35

Introducci贸n a DevSecOps

36

Firmas de seguridad

37

Pruebas est谩ticas de seguridad

38

Escaneo de contenedores

39

Escaneo de dependencias

40

Pruebas din谩micas de seguridad

41

Gitlab security dashboard

Distribuci贸n

42

Continuous Delivery (CD)

43

Ambientes

44

Review apps

45

Estrategias de Distribuci贸n

46

Feature Flags

47

Rollback

Monitoreo

48

驴Por qu茅 monitorear?

49

M茅tricas de desempe帽o (performance metrics)

50

M茅tricas de salud (health metrics)

51

Metricas de equipo

52

Rastreo de errores

Conclusiones

53

驴Por qu茅 desarrollar con Gitlab?

A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Gitlab CI

23/53
Recursos

Gitlab CI es el hub central de automatizaci贸n de Gitlab, es el pedazo que podemos configurar libremente para generar las automatizaciones necesarias para que nuestro flujo de trabajo requiera poca o ninguna interacci贸n humana.

  • Continuamente construye, prueba y despliega cambios peque帽os al c贸digo.
  • Se configura con el archivo gitlab-ci.yml

Tambi茅n nos permite realizar Continuous Delivery y Continuous Deployment.

Aportes 22

Preguntas 5

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

脡stos son los servicios de Gitlab para CI y CD

  1. Verificar
  2. Empaquetar
  3. Lanzar
    • Continuous Deployment, implementando autom谩ticamente la aplicaci贸n en producci贸n.
    • Continuous Delivery, haga clic manualmente para implementar su aplicaci贸n en producci贸n.
    • Implemente sitios web est谩ticos con GitLab Pages.
    • Env铆e funciones a solo una parte de sus pods y permita que un porcentaje de su base de usuarios visite la funci贸n implementada temporalmente con Canary Deployments.
    • Implementaci贸n de funciones detr谩s de Indicadores de funciones.
    • Agregue notas de lanzamiento a cualquier etiqueta de Git con GitLab Releases.
    • Vista del estado actual y el estado de cada entorno de CI que se ejecuta en Kubernetes con Deploy Boards.
    • Implementa tu aplicaci贸n en un entorno de producci贸n en un cl煤ster de Kubernetes con Auto Deploy.

Les dejo un gitlab-ci.yml funcional para SpringBoot que mide:

coverage (jacoco)
mutation (pitest)
Construye la imagen docker y la publica en el registry de gitlab.

image: docker:latest
services:
  - docker:dind

variables:
  DOCKER_DRIVER: overlay

stages:
  - coverage
  - mutation
  - build
  - package

gradle-build:
  image: gradle:alpine
  stage: build
  variables:
    GRADLE_OPTS: "-Dorg.gradle.daemon=false"

  before_script:
    - export GRADLE_USER_HOME=`pwd`/.gradle
  script:
    gradle bootJar
  artifacts:
    paths:
      - build/libs/*.jar
    expire_in: 1 week

gradle-test:
  image: gradle:alpine
  stage: coverage
  script:
    gradle test jacocoTestCoverageVerification

gradle-mutation:
  image: gradle:alpine
  stage: mutation
  script:
    gradle pitest

docker-build:
  stage: package
  script:
    - docker build -t registry.gitlab.com/msgoon6-scholar/schollar-service .
    - docker login -u msgoon6-************ -p ******************** registry.gitlab.com
    - docker push registry.gitlab.com/msgoon6-scholar/schollar-service

Variables
.

  • Trigger Variables: Son variables automatizadas cuando se detona un nuevo build.
    Project Variables (y Protected Variables): Son variables que se pueden definir para que sean expuestas 煤nicamente en un proyecto espec铆fico o algunas ramas espec铆ficas.

  • Group Variables: Son variables que se pueden definir para que est茅n expuestas en un grupo espec铆fico.

  • YAML Job Level Variables and YAML Global Variables: Son variables que se pueden incluir en el archivo de configuraci贸n yaml.

  • Deployment Variables: Son variables enfocadas a almacenar informaci贸n o credenciales para la integraci贸n con servicios externos, por ejemplo kubernetes, para hacer el deploy del proyecto.

  • Pre Defined Variables: Son variables predefinidas que se exponen por parte de GitLab en cada uno de los trabajos de automatizaci贸n.

Otro que investigue, y que me pareci贸 muy util fue :
-merge_requests

Este sirve para especificar (por medio de only),que job correr谩 al momento de solicitar un merge, lo veo muy 煤til para ambiente de pruebas QA o de perfomance,de resto no se me ocurre para qu茅, de momento.

Ejemplo:

<code>
test:
	stage:QA
	script: ./QA
	only:
		-merge_requests

en este caso el job test correr谩 solo al solicitar un merge

Es posible configurar el gitlab-ci.yml dentro de un directorio .gitlab-ci? parecido a como se maneja en circle ci

/gitlab-ci/git-lab-ci.yml

si est谩n probando con una app de RubyOnRails les comparto el pipeline que hice para correr los test unitarios con rspec.

stages:
  - test

.base:
  image: ruby:2.7.0
  cache:
    paths:
      - apt-cache/
      - vendor/ruby
    policy: pull
  before_script:
    - gem install bundler --no-document
    - bundle install --jobs $(nproc) "${FLAGS[@]}"

test:rspec:
  stage: test
  extends: .base
  script:
    - bundle exec rspec

Seg煤n lo que encontr茅 acerca de before_script, es que es utilizado para cuando varios jobs comparten un mismo script, para esto se agrupan esos comandos en com煤n dentro de esta etiqueta, como por ejemplo:

  • composer install

Y el keyword de after_script es la agrupaci贸n de scripts que se ejecutar铆a despues de cada job definido, incluso si fallan, particularmente lo ver铆a con algo de utilizad para generar alg煤n reporte, o notificar el resultado a alg煤n administrador, pero tengo mis dudas a煤n.

Documentaci贸n:
https://docs.gitlab.com/ee/user/project/pages/getting_started_part_four.html#before-script

https://docs.gitlab.com/ee/ci/yaml/#before_script-and-after_script

.gitlab-ci.yml
.
El archivo de configuraci贸n de GitLab CI funciona a traves de keywords. Cada una de estas keywords nos permiten configurar los trabajos.

Es un tipo de c贸digo declarativo, es decir que no necesitamos generar mucha l贸gica en el archivo, si se necesita incluir l贸gica adicional en el archivo, lo m谩s conveniente es pasar esa l贸gica a otros archivos, de tal manera que gitlab-ci.yml nos especifique cuales son los trabajos de alto nivel.
.

  • Image: GitLab CI trabaja por medio de contenedores. Se debe declarar un contenedor al principio para poder definir el ambiente global en el cual vamos a trabajar, por ejemplo, si tenemos el proyecto bajo Angular el ambiente a escoger ser铆a el de Node, pero si tenemos el proyecto en Flask el ambiente a escoger ser铆a el de Python.

  • Stages: Son los pasos o fases espec铆ficos por los cuales va a pasar nuestro proceso de integraci贸n continua. Por lo general, se establecen 3 fases: build, test y deploy, pero se pueden incluir pasos adicionales como documentaci贸n.

  • Jobs: Se pueden nombrar los jobs como se considere. Cada Job va a pertenecer a un Stage, se le puede definir las Variables y los Scripts que es donde nosotros automatizamos.

Profe quiero ser como usted cuando sea grande!

Documentacion de Variables en GitLab CI:
https://docs.gitlab.com/ee/ci/variables/README.html

Hola!, tengo una duda acerca del comando 鈥榠mage鈥, cuando David menciona que se pueden seleccionar entre miles de im谩genes, de d贸nde las obtiene? Gitlab tiene su propio repositorio de im谩genes algo parecido a Dockerhub?

Le铆 acerca de refs , la cual dice que es una simplificaci贸n de only y except.
por ejemplo:

<code>
- test:
	only:
		-master
		-test

/esto quiere decir que el job 鈥渢est鈥 correr谩 solo si es ejecutado desde la rama master o test del repositorio, por lo que esta impl铆cito que en el resto de ramas NO lo har谩./

No entend铆 nada salu2

El manejo de las fases de c贸digo (production, pre production, etc) se materializa a trav茅s de ramas, a esto se le llama Gitlab Workflow, pueden darle una mirada ac谩: https://docs.gitlab.com/ee/topics/gitlab_flow.html

Declarativo es que no necesitamos hacer mucha l贸gica. Simple, sencillo O:

Entiendo que en una instancia self hosted de GitLab, el servidor de GitLab tiene que tener instalado docker, para traer y construir las im谩genes, cierto?

  • Aqu铆 le dejo los keywords que se pueden usar en el archivo .gitlab-ci.yml.

  • Aqu铆 unos ejemplos de .gitlab-ci.yml.

B谩sicamente Continuous Integration es hacer un build automatico ya sea de un frontend o una imagen de docker por ejemplo. Continuous Delivery es tener la versi贸n entregable lista por ejemplo la versi贸n del proyecto de desarrollo/staging y Continuous Deployment es desplegar nuestra aplicaci贸n en producci贸n de manera autom谩tica.

Descripci贸n de gitlab-ci.yml